Re: On BGP and VPLS

Alex,

> Folks,
> 
>  As an Area Director, and an IESG member, I try to express my
>  technical opinions during WG discussions only when it really matters,
>  e.g., when I think a WG is going in a wrong direction, or a
>  technically bad idea is being considered. However, I believe that ADs
>  do need to do this to prevent surprises when documents get to the
>  IESG. Also, when documents are ready to go to the RFC status, it is
>  the responsible AD who takes them to the IESG and defends them there,
>  so I think it is useful for ADs to communicate their concerns to the
>  WGs when such exist.
> 
>  I have been watching the discussion about draft-kompella-ppvpn-vpls
>  on the mailing list and didn't get the feeling that certain aspects
>  of it have been taken seriously enough. Without an attempt to respin
>  the heated discussion again, it seems it would be useful for the WG
>  if I provided some feedback on the topic now, when the WG is
>  discussing the direction in which it should proceed.
> 
>  First of all, let me remind you the message Scott and I brought to
>  the WG in Yokohama--the IESG is very concerned about the tendency of
>  using routing protocols (and BGP in particular) as a universal
>  transport mechanism, and a _very_ strong case would need to be made
>  if the WG decided to go with such a proposal.

If the IESG is so much concerned, then it is the IESG's responsibility
to substantiate their concerns with *solid* technical arguments
that are of practical significance, and not just say that "the IESG
is very concerned". So far the IESG clearly failed to do so, as
what you put in the rest of this message either lacks solid technical
justification (see Pedro's replies to you) or practical significance,
or both.

Yakov.

> 
>  More specifically, below I tried to put together a list of concerns
>  I have about the approach described in draft-kompella-ppvpn-vpls,
>  that I would like the WG to consider.
> 
>  1. Use of the NLRI field
> 
>    As an IP routing protocol, BGP uses the NLRI field to carry IP
>    reachability information in the form of IP prefixes. Prefixes
>    within the NLRI field are used for two main purposes in BGP: a) as
>    the destination/mask pair in the routes installed by BGP in the
>    routing table, and b) as a handle to an entry in the BGP RIBs.
> 
>    The document in subject changes the semantics of the NLRI field
>    quite substantially even when compared to 2547. First, all of its
>    IP prefix-related properties are lost. There is no more IP routing,
>    or any addressing information in it. Second, the notion of TLVs is
>    introduced inside this field, which a) is not needed in BGP as an
>    IP routing protocol, and b) because of its variable length property
>    changes the nature of the NLRI contents, i.e., it's being a stable
>    handle in the BGP database. To solve these problems the
>    implementations would need to use only a part of the contents of
>    the NLRI field as the handle used to index within the RIBs, and
>    store the rest as attributes.
> 
>  2. Distribution of information
> 
>    When used as an IP routing protocol, BGP distributes routes among
>    all participating routers. Each router (PE or P using VPN
>    terminology) is interested in _all_ routes received from its peers;
>    it selects the best path for each prefix if multiple are available
>    and installs it in it's routing table; the best paths are
>    propagated further to other peers.
> 
>    The way BGP is used in the document results in a situation where
>    information relevant only to a subset of routers (e.g. PW-specific,
>    or VPLS-specific info) is sent to all PEs participating in the BGP
>    domain. More than that, P routers, usually used as route reflectors
>    in IP routing, end up storing all information while they are not
>    using any of it locally.
> 
>    Note also, that best path selection that is normally performed by
>    BGP when it receives information about the same prefix from
>    multiple peers, is not needed in the VPLS case, and (even if
>    implementations decided to apply the same algo as in regular BGP)
>    would just be an artifact.
> 
>    The above exposes the difference between the routing nature of BGP
>    when used for IP (where reachability info is distributed and the
>    path properties are as important as the info itself), and its
>    purely transport application in the proposal (where only the fact
>    of information delivery is important.)
> 
>    Interestingly enough, from the transport perspective, BGP, though
>    reduces the number of sessions a given PE has to maintain (and thus
>    the sender's complexity), introduces additional overhead from
>    the receiver's perspective--if a PE router has multiple BGP
>    sessions (which is normally the case), it will receive the same
>    information more than once, while clearly a single copy is enough.
> 
>  3. Aggregation of information for large-scale operation
> 
>    When distributing information among a large number of systems, it
>    is important to be able to aggregate information as it travels
>    further ahead to ensure scalability of the system. In routing this
>    is achieved by summarizing a set of prefixes and announcing them as
>    a less specific prefix. For example, AS'es in the Internet do not
>    exchange granular IP prefixes visible inside IGPs, but instead send
>    each other aggregate prefixes via BGP.
> 
>    It is not clear to me how, given the format of the NLRI field, VPLS
>    information can be aggregated using the proposal in the document.
> 
>  The above gives me a very uncomfortable feeling that the proposal
>  is stretching BGP to perform functions it was not designed for.
> 
>  Below are some additional points that should be taken into
>  consideration.
>    
>  4. Backwards compatibility and SW upgrade requirements
> 
>    Because the proposal suggests using a new AFI/SAFI combination, PE
>    routers will not be able to announce VPLS information using the
>    existing BGP infrastructure. All BGP speakers in a SP's network,
>    including the P routers, will have to be upgraded with new SW,
>    though information needs to be exchanged only among the PEs.
> 
>  5. Coupling of VPLS and BGP SW
> 
>    Putting VPLS-related functions in BGP leads to two unwanted
>    consequences:
> 
>     a) Lesser BGP code stability--bugs in the VPLS part of the code
>        will likely affect parts of BGP used for Internet routing,
>        thus increasing the chances of BGP failures in SP networks.
>        The same argument works in the opposite direction.
> 
>     b) Potential dynamic effects--since with a BGP-based approach,
>        VPLS- and routing-related processes are likely to share
>        the same internal router resources (such as timers, threads,
>        locks/mutex'es, queues, memory pools), dynamics of the VPLS
>        system are likely to influence the dynamics of the routing-
>        related functions and vice versa. The larger the overlap
>        between the two systems, the higher are the chances of such
>        interference.
> 
>  My recommendation would be for the WG to consider these points.
> 
>  Also, one quite important question I saw brought up by Eric in this
>  discussion was about the p2p nature of PW signaling in VPLS. I think
>  this is one of the key questions that we need an agreement on.
> 
>  The question asked by Robert today is also quite interesting.
> 
>  Regards.
>  
> --
> Alex Zinin
> IETF SUB-IP Area Co-Director
> 
> 
>