Subject: Fwd: On BGP and VPLS

From: Alex Zinin <[email-masked]>
Date: Fri, 2 May 2003 19:22:48 -0700

FYI below.
-- 
Alex
http://www.psg.com/~zinin/

This is a forwarded message
From: Alex Zinin <[email-masked]>
To: [email-masked]
Cc: 
Date: Friday, May 2, 2003, 7:14:39 PM
Subject: On BGP and VPLS

===8<==============Original message text===============
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.

 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

===8<===========End of original message text===========