Subject: [Diffserv] TR: Support to the PIB standardisation effort (long message)

From: JACQUENET Christian FTRD/DMI/CAE <[email-masked]>
Date: Mon, 25 Mar 2002 16:53:55 +0100

Folks,

There has been some discussion recently on the rap mailing list about the
usefulness of promoting the PIB standardisation effort, and I've just
realized that the message I sent today may be worth sending it to the
diffserv and ipsp mailing lists as well - my apologies for any inconvenience
this may have caused.

Best regards,

Christian.

>  -----Message d'origine-----
> De : 	JACQUENET Christian FTRD/DMI/CAE  
> Envoyé :	lundi 25 mars 2002 11:53
> À :	[email-masked]'; 'Randy Bush'; 'Wijnen, Bert (Bert)'
> Objet :	Support to the PIB standardisation effort (long message)
> Importance :	Haute
> 
> Dear colleagues,
> 
> After having attended the IETF 53 rap meeting (but not having found the
> time to check all the messages on this topic), I'd like to share my humble
> thoughts on the PIB standardisation effort with the rap community
> (apologies for a late jumping into this dicussion).
> 
> My personal 12-year experience of designing and deploying IP networks and
> services has led to the following facts and observations:
> 
> 1. I'm not aware of a single network operator/service provider that uses
> SNMP for configuration purposes. Two main reasons for this:
> *	The network devices CANNOT be configured via SNMP, because of
> vendors' technological choices. SNMP is (can) only (be) used for the "F"
> function of the FCAPS sequence of the management area (e.g. we've been
> performing a quick dump on the ifTable on a daily basis for years),
> *	SNMP is not supported by a reliable transport mode, which is an
> issue for conveying configuration information towards operational
> equipment, not to mention the security issues.
> 
> 2. As a consequence of the above, we've been using vendor-specific CLI
> syntax for configuration purposes, hence the need to develop a high level
> of expertise that has to be replicated for each technology being used by
> our networks and services. 
> 
> 3. As the Internet is becoming a privileged support for a wide range of
> service offerings, ranging from dial-up access to more sophisticated
> services like QoS-based IP VPNs, the magnitude of the aforementioned CLI
> usage has dramatically increased, as well as the time to actually
> configure all the devices involved in the provisioning of a given service
> accordingly. 
> To give an example, the deployment of an IPSec-based IP VPN that:
> *	Interconnects 10 sites
> *	*Only* supports manual key configuration
> *	Imposes static routing (because of the vendor's implementation, but
> that's another question)
> *	Is partially meshed
> *	Supports Internet access
> *	Supports dial-up IP VPN users (hence the possible use of another
> kind of equipment, as well as a L2TP-declined configuration information)
> ...takes something like 4 to 6 hours to *prepare* the configuration files,
> not to mention the additional features like QoS management and the user
> profile management (including specific filters). We then need to download
> the files to the appropriate devices and check the IP connectivity, as
> well as the overall correctness of the configuration information. 
> Obviously, this is the kind of task that has to be repeated for every IP
> VPN sold, not to mention the available option of other technologies (e.g.
> 2547-based IP VPNs), depending on the size of the VPN, amongst other
> considerations that include traffic engineering aspects.
> 
> 4. As a consequence of fact #3, the search for automation (of service
> provisioning) has rapidly become one of our most important Graal quests,
> not only because such automation is expected to dramatically reduce the
> cost of deploying (and exploiting) a wide range of service offerings, but
> also because the level of implementation-specific expertise required to
> deploy such services has become incompatible with the "level of knowledged
> people/number of people working in our TAC" ratio.
> 
> 5. As an additional consequence of facts #2 and #4, we've decided to
> investigate the COPS-PR track, because of the nicely formulated arguments
> that David (Durham) and others have already exposed on this mailing list,
> but also because the COPS-PR specification effort is on the standards
> track (at least it used to be). 
> This is why we specified, developed and implemented an IP Traffic
> Engineering PIB (see
> http://search.ietf.org/internet-drafts/draft-jacquenet-ip-te-pib-01.txt) .
> This is also why we developed and implemented the IPSec PIB, currently
> being standardised in the ipsp working group. This effort has led to the
> development of prototypes that have shown something between a 1:1000 and
> 1:10000 ratio for the provisioning of the corresponding configuration
> information to the network devices we currently operate in our networks,
> i.e. a COPS-PR-based dynamic provisioning scheme has yielded a 1000 to
> 10000 faster configuration task than the CLI-based approach (by using
> standardised formatted data), with all the guarantees provided, as far as
> the actual processing by the network devices is concerned.
> We've also demonstrated these prototypes to our operational branches who
> have shown a strong interest in this technology, especially when
> mentioning that such effort is supported by a couple of IETF working
> groups.
> 
> Now, to briefly answer to a couple of comments that have been made during
> the rap WG meeting in Minneapolis:
> 
> *	It is untrue that vendors are reluctant to implement COPS-PR as well
> as the approriate PIB modules. I'm not supposed to make any kind of
> advertisement on this list, but we've been evaluating a couple of
> commercially available solutions that implement a sometimes adapted
> version of the DiffServ PIB, and I'm also aware of several other vendors
> that claim that kind of support.
> *	I have to say that the argument (apparently developed by some
> network operators) of the need for a single protocol is pathetic: the
> "one-size-fits-all" has *never* existed (see the RADIUS, TACACS, DIAMETER
> options for user/device identification/authentication, the
> IPCP/RADIUS-inferred IPCP/DHCP options for address allocation, the
> RIP/OSPF/IS-IS options for intra-domain routing, etc.), and I personnally
> find VERY useful the existence of such various options, because we can
> make them adapt to a range of specific environments, hence, for example,
> the co-existence of different routing protocols within our domain(s).
> 
> We've been involved in the COPS-PR development stuff for more than two
> years, and our first results have proven very encouraging (including from
> a scalability perspective).
> 
> So, YES, I FULLY support the PIB standardisation effort within the IETF,
> and I would feel very frustrated if the IESG decided, for some reason, to
> abandon such a strategic standardisation effort. I also regret that only a
> few working groups have adopted this PIB standardisation effort.
> 
> Comments welcome.
> 
> Best regards,
> 
> Christian Jacquenet
> France Telecom R & D
> 
> 
> 
>     _________________    ________  ______  ______
>    /_____________   /__ /_    _ / /     / /     /   Christian "I'm a ZZ
> Fan" Jacquenet
>       /_________/  /  /   /  /   /  /  / /  /__/    France Telecom R & D
> DMI/SIR
>                /  /  /___/__/___/_____/_/__/____   "It's not jewelry she's
> talkin' about,
>               /__/  /__________________________/_ It really don't cost
> that much."  
>                 /_______________________________/ - Pearl necklace.
>