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

Re: IESG statement on BGP overloading for VPNs

some grammar nits, some things I don't understand.....

--On 15. oktober 2003 23:36 -0700 Alex Zinin <zinin@psg.com> wrote: 
Below is the proposed draft text of the IESG statement. Comments
welcome.

Alex


 The IESG has been requested to provide its opinion on the issue
 of routing protocol overloading as applied to the BGP extensions
 proposed for VPN discovery and signaling described in the following
 documents:

  1. draft-ietf-l2vpn-vpls-bgp
  2. draft-ietf-l3vpn-bgpvpn-auto

 Consultation with the Routing Area and O&M Area directorates, and the
 discussion on the related topics on the Routing Area mailing list,
 brought up several concerns:

1. BGP is part of the Internet's critical infrastructure.

Excessive number of BGP applications increases the size of the
^An 
     BGP code running on the Internet routers, its complexity, memory
     and bandwidth requirements for routers, increases the risk of
     interference between the IP routing-related BGP code and new
     applications, as well as the risk of interference between the
     Internet BGP system and its other applications.

  2. Routing protocols should not be used as universal transport
     mechanisms.

     There are two potential ways of using routing protocols to
     distribute additional information--using the same protocol
s/additional information/information required for other applications/?????

     infrastructure as for regular IP routing (integrated model) and
     using a separate independent instance of the protocol with
     possible adjustments (parallel model).

     Distribution of arbitrary information using the integrated model
     has the potential of affecting the convergence characteristics of
     the original routing system if the amount of information being
     distributed, its growth and change dynamics are such that they
     lead to increased consumption of such network resources as router
     CPU and link bandwidth. Thus, every new type of information added
     to a routing protocol should be carefully considered for possible
     effects on the existing routing system.

     Potential problems related to the parallel model are less
     obvious, since the details of network (and router) resources
     separation and process decoupling between the protocol
     applications and instances are now hidden behind implementation
     specifics. However, one can still identify increased risk of
     interference between IP routing and other routing protocol
     applications compared to distribution of information using
     separate (not routing) protocols.

don't see that in the case of "protocol X" being deployed on separate hardware; do see it in the case of reusing the same hardware.

3. ????

a very compelling argument :-)

The IESG recommendations are as follows:

  1. Following the long-standing practice of hosting the work on
     protocol extensions within the WG responsible for the protocol,
     the BGP-specific parts of the proposal should be submitted to
     the IDR WG and discussed there.

  2. Consensus within the IDR WG should be a requirement for
     continuing the work on the proposed BGP extensions. It is the
     responsibility of the proponents to show why BGP is the right
     (and safe) choice for the functionality being addressed, as
     opposed to others having to show why the mechanism is broken.

  3. If the IDR WG decides that using the MP-BGP framework for
     discussed applications is appropriate, the IESG recommends
     considering instantiation of a separate protocol, inheriting
     the interesting MP-BGP functionality, yet having its evolution.

  4. Considering that the MP-BGP framework is already used by multiple
     applications (including IPv4, IPv6, unicast and multicast routing),
     the IESG recommends that the IDR WG performs the analysis of how
     much separation between different AFI/SAFI sets is achievable and
     addresses the identified issues where necessary.

I'm not sure we need to force reuse of the BGP protocol formats (such as was done in TRIP) through the IDR WG.
It seems that what you look for is:

- If the application promoter decides to not use a BGP-like protocol, the IDR WG will not interfere
- If the application promoter decides to use a BGP-like protocol, the IDR WG will give advice on whether to integrate it in the regular BGP deployment framework or instantiate another protocol that "looks like BGP"
- For the "integrated" model, the IDR WG is required to have consensus that this is OK in order to do it

did I understand it correctly?

Harald