[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Support to the PIB standardisation effort (long message)



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

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:

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:

...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:

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.