Subject: Support to the PIB standardisation effort (long message)

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

[ post by non-subscriber ]

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.