Are there any good (published) BCPs for building out Municipal WiFi networks? Particularly in the security/authentication/scaling areas?
Thanks in advance,
DJ
Ask Earthlink, they just announced pulling out of Philly .. and I
guess they had a working deployment going by the time they pulled out
(and the reasons for that pullout would do for a great white paper all
by themselves, I expect...)
How is the state of arts of NETCONF (RFC 4741) protocol?
Is there any Network Management System Deployed which is base on NETCONF?
Do you think security products (like Firewall, IDS/IPS and Security
Operation Centre) can benefit from NETCONF?
Thanks in advance,
Devin
How is the state of arts of NETCONF (RFC 4741) protocol?
Is there any Network Management System Deployed which is base on NETCONF?
I've personally been waiting for the data modeling to be standardized. Yes, it's great and wonderful to have a consistent method of talking to network devices, but I also want a standard data model along with it.
Do you think security products (like Firewall, IDS/IPS and Security
Operation Centre) can benefit from NETCONF?
I believe any network device can benefit from netconf.
I've personally been waiting for the data modeling to be
standardized. Yes, it's great and wonderful to have a consistent
method of talking to network devices, but I also want a standard data
model along with it.
does this not imply that all devices would need to be semantically
congruent? if so, is this realistic?
randy
Randy Bush writes:
[in response to John Payne <john@sackheads.org>:]
I've personally been waiting for the data modeling to be
standardized. Yes, it's great and wonderful to have a consistent
method of talking to network devices, but I also want a standard
data model along with it.
does this not imply that all devices would need to be semantically
congruent? if so, is this realistic?
Personally I don't think it is.
The way that configuration is structured is something that at least
some vendors use to differentiate themselves from each other. (Though
other vendors make a point of being compatible with some "industry
standard CLI".)
So if you think that configurations in NETCONF should be similar to
the "native" configuration language, that doesn't bode well for
industry-wide standardization of a NETCONF configuration data model.
It might still be possible to have a common NETCONF data model, but
then that would probably be quite different from the (all) "native"
configuration languages; much in the same way as SNMP MIBs are
(structurally) different from how information is presented at the
CLI. Personally I'm not sure that this would be a very useful
outcome, because there would necessarily be a large lag between when
features are implemented (with a "native" CLI to configure them of
course) and when they can be configured through NETCONF.
Maybe the best we can shoot for is this:
* A common language to describe parts of NETCONF configuration. The
newly chartered IETF NETMOD working group[1] is working on this.
Vendors can then describe their specific NETCONF data models using
this language, and tool writers can use these descriptions to
generate code for applications that want to manipulate device
configurations.
* Common data models for certain well-understood parts of NETCONF
configuration. This could include simple "atomic" things such as
how to write an IP address or a prefix in (NETCONF) XML, or
configuration of standardized protocols such as OSPF, IPFIX etc.
The problem is how well will this support migration from
vendor-specific configuration to standardized configuration - which,
as I said, is always bound to lag far behind. And even if/when an
aspect of a configuration model (let's say for OSPF) is
standardized, vendors are bound to extend that model to support
not-yet-standardized extensions (e.g. sub-second timers, BFD). This
will be another challenge to support. (But there are smart people
working on this 
BCP #58,271,432--which basically states "Don't," comes highly recommended.
Instead, investigate your nearest .16e or evdo rev. A reseller. In the
case of .16e, most available APN's are built around user and
transport/transit abstractions, assuming shared-facilities, virtual
providers, etc. The equipment used in both is a far cry from anything
802.11.
p.
Greetings,
Interesting comment Paul. However, 16e and evdo are a "bit" heavy with infrastructure to support mobility. Before giving that answer, you may want to ask Deepak if he NEEDS mobility....
Chris
Deepak Jain wrote:
Are there any good (published) BCPs for building out Municipal WiFi networks? Particularly in the security/authentication/scaling areas?
Interesting comment Paul. However, 16e and evdo are a "bit" heavy
with infrastructure to support mobility. Before giving that answer,
you may want to ask Deepak if he NEEDS mobility....
He needs mobility. If he doesn't know that, it means he hasn't done
his due diligence properly.
Cheers,
-- jra