One document matched: draft-jamieson-bgp-solicit-00.txt

Network Working Group                                D. Jamieson
Internet Draft                                       Nortel Networks
Expiration Date: May 1999                            R. Wang
                                                     Nortel Networks


                   Solicitation Extensions for BGP-4

                  <draft-jamieson-bgp-solicit-00.txt>

Status of this Memo

   This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
   ftp.isi.edu (US West Coast).


Abstract

   This document describes an extension to BGP-4 which may be used by a
   BGP-4 speaker to solicit Virtual Private Network (VPN) reachability
   information from other IBGP speakers.

   The motivation of the proposed technique is to provide a means of
   reducing the memory requirements of routers which use BGP-4 to
   distribute VPN reachability information as described in [1] and [4].

   The extension is backward compatible in that a router which supports
   the extension can interoperate with a router which doesn't.


 1. Introduction

   Recently, several drafts have described techniques to dynamically
   establish VPN tunnels across a provider network. Many of the drafts
   have proposed that BGP-4 be used to distribute either VPN



Jamieson, et al                                                 [Page 1]

Internet Draft     draft-jamieson-bgp-solicit-00.txt       November 1998


   reachability information or VPN route information.

   The methods described in [1] generally don't depend on outbound
   policy filters to control the distribution of VPN reachability
   information. When a new VPN member site joins a VPN the information
   regarding that site is distributed to all other Provider Edge (PE)
   routers in the network. This allows new VPN member sites to join a
   VPN with very little or no intervention on the part of the provider.

   On the other hand, the methods described in [4] do rely on outbound
   policy filtering to control the distribution of VPN route
   information.  PE routers and route reflectors need to be provisioned
   with a list of peers which require specific VPN route information.
   When a new VPN member site joins a VPN, policy filtering may have to
   be changed on multiple devices.

   In a large provider network which supports a large number of VPN
   subscribers, the methods described in both [1] and [4] could have
   serious scaling problems.

   Using the methods described in [1], the amount of VPN reachability
   information that would be stored in the BGP-4 speakers' Adj-RIB-In
   could be very large.  Whereas, the percentage of that information
   relevant to any particular BGP-4 speaker might be small.

   Using the methods described in [4], there would potentially be two
   problems.  First, the amount of policy required to control VPN route
   information distribution would become onerous. Second, in a large
   network, route reflectors would be required. Depending on the
   distribution of VPN sites and the complexity of policy filtering, the
   route reflectors may be required to store huge amounts of information
   in their Adj-RIB-In.

   The following network scenario is based on the methods described in
   [1]. The scenario makes some assumptions on the size of a future
   network. One can debate the numbers to a certain extent but it is
   clear that there is a problem:

     Number of Provider Edge nodes in provider network:     2,000
     Number of VPN interfaces per Provider Edge (PE):       1,000
     Average number of sites belonging to a VPN:               10
     Number of VPN entries distributed to each PE:      2,000,000

     Memory consumption estimate:
     Conservative size of BGP Adj-RIB-In entry:                30 bytes
     Size of BGP Adj-RIB-In:                           60,000,000 bytes

   Given the assumptions above, 10,000 VPN Adj-RIB-In entries on an



Jamieson, et al                                                 [Page 2]

Internet Draft     draft-jamieson-bgp-solicit-00.txt       November 1998


   average PE would be acted upon. In other words, those 10,000 entries
   would be passed to the PE's directly connected Customer Premises
   Equipments (CPEs) for the purpose of establishing VPN tunnels.
   Whereas, 1,990,000 or 99.5% of the entries would have no value and be
   ignored.

   Some BGP-4 implementations allow entries which should be in Adj-RIB-
   In to be discarded; however, the entries may be required at a later
   time when a new VPN member joins. Currently, if a BGP-4
   implementation allows Adj-RIB-In entries to be discarded, the only
   way to retrieve them at a later time is to close the peer connection
   and re-establish it. In a large network, this would be very
   disruptive.

   This draft proposes a technique which would allow BGP-4 to discard
   Adj-RIB-In entries that are not relevant and solicit those that are.


 2. Terms and Definitions

    VPN Reachability Information (VRI)
    - A BGP route associated with a VPN. It contains route information
      as defined in [2] and VPN specific information.

    Solicitation
    - A request for VRI from an IBGP speaker to other IBGP speakers.

    Solicitation Capable IBGP (SC-IBGP) speakers
    - A router which has an implementation of BGP-4 that supports the
      solicitation extensions and solicitation is enabled on that
      router. All IBGP speakers on that router are called SC-IBGP
      speakers.

    Non-Solicitation Capable IBGP (NSC-IBGP) speakers
    - A router which has an implementation of BGP-4 that either does
      not support the solicitation extensions or solicitation is
      disabled on that router. All IBGP speakers on that router are
      called NSC-IBGP speakers.


 3. Design Criteria

    BGP Solicitation was designed to satisfy the following criteria:

    - Dynamic, non-disruptive distribution of VRI

    - Ability to discard non-relevant VRI




Jamieson, et al                                                 [Page 3]

Internet Draft     draft-jamieson-bgp-solicit-00.txt       November 1998


    - Compatibility

      It must be possible for NSC-IBGP speakers (including route
      reflectors) to continue supporting the general VPN architecture
      without any loss of VRI.


 4. Solicitation Path Attributes

   This document introduces two new BGP-4 path attributes: Solicitation
   Request and Solicitation Withdraw.

  4.1. Solicitation Request Path Attribute (Type Code 16):

   The Solicitation Request (SOL_REQ) path attribute is an optional
   transitive attribute of length 0. It is used by a SC-IBGP speaker to
   solicit VRI from other SC-IBGP speakers.

  4.2. Solicitation Withdraw Path Attribute (Type Code 17):

   The Solicitation Withdraw (SOL_WD) path attribute is an optional
   transitive attribute of variable length.

   The SOL_WD path attribute consists of a list of four octet values,
   each of which indicates membership withdraw from a particular VPN.
   Each SOL_WD path attribute is represented by a list of tuples of form
   <length, VPN identifiers>, where each tuple is encoded as shown
   below:

          +-----------------------------+
          | Length (2 octets)           |
          +-----------------------------+
          | VPN identifiers (variable)  |
          +-----------------------------+

          Length - total length of the VPN identifiers in octets
          VPN identifiers - a list of withdrawing VPN identifiers

   An UPDATE message that contains the SOL_WD attribute is not required
   to carry any other path attributes.

   The solicitation extension path attributes must not be passed to EBGP
   peers.


 5. Solicitation of VPN Reachability Information

   The first time a SC-IBGP speaker A advertises a VRI for VPN X, A must



Jamieson, et al                                                 [Page 4]

Internet Draft     draft-jamieson-bgp-solicit-00.txt       November 1998


   include a SOL_REQ path attribute along with the VRI. This VRI must be
   distributed to all IBGP peers. It should be noted that subsequent
   VRIs advertised by A for VPN X should not include the SOL_REQ path
   attribute.

   When a SC-IBGP speaker B which supports VPN X receives the VRI
   originated from A (may come from a route reflector), B must
   distribute all of its VRIs associated with VPN X back to the peer
   from which it received the solicitation.

   A SC-IBGP speaker not in VPN X may discard the reachability
   information from A (i.e. may not store it in its Adj-RIB-In).

   A NSC-IBGP speaker C receiving A's UPDATE message must ignore the
   SOL_REQ path attribute, store the reachability information in its
   Adj-RIB-In and continue to distribute its VRIs for VPN X to all of
   its peers.  Meanwhile, A should store all reachability information
   from C in its adj-RIB-In regardless whether C participates in the
   same VPN(s) or not.


 6. VPN Membership Withdraw

   When a member of VPN X unsubscribes, a SC-IBGP speaker A will notify
   all other IBGP peers known to support VPN X. Multiple members of VPN
   X may be supported by A. But if the last member of VPN X is withdrawn
   from A, all other SC-IBGP speakers that support X should stop sending
   VRIs related to VPN X to A.

   To withdraw membership from VPN X, a SC-IBGP speaker A may include a
   SOL_WD path attribute along with the unfeasible route(s) in its
   UPDATE message. Upon receiving this UPDATE message, a SC-IBGP speaker
   B must withdraw the unfeasible route(s). B must also stop sending
   reachability information related to VPN X to A if the last
   reachability information related to VPN X from A has been withdrawn.

   Means to withdraw VRIs on NSC-IBGP speakers need further
   investigation.


 7. Operation of BGP Route Reflectors

   Operation of BGP route reflectors which do not support solicitation
   remains the same as defined in section 5 of [3].

   Operation of BGP route reflector which supports solicitation is
   proposed to change to the following:




Jamieson, et al                                                 [Page 5]

Internet Draft     draft-jamieson-bgp-solicit-00.txt       November 1998


   Each route reflector must keep track of the VPN associated with each
   of its SC-Client peers. When a route is received by a route
   reflector, it selects the best path based on its path selection rule.
   After the best path is selected, it must do the following depending
   on the type of peer it is receiving the best path from:

      1) A route from a Non-Client peer

      - reflect to all SC-Client peers in the same VPN; and
      - reflect to all NSC-Client peers.

      2) A route from a Client peer

      - reflect to all Non-Client peers; and
      - reflect to SC-Client peers in the same VPN other than the
        originator; and
      - reflect to all NSC-Client peers other than the originator.

      3) A route from an EBGP peer

      - reflect to all Non-Client peers; and
      - reflect to SC-Client peers in the same VPN; and
      - reflect to all NSC-Client peers.


 8. Security Considerations

   Security issues are not discussed in this memo.


 9. Intellectual Property Considerations

   Nortel Networks may seek patent or other intellectual property
   protection for some of all of the technologies disclosed in this
   document. If any standards arising from this document are or become
   protected by one or more patents assigned to Nortel Networks, Nortel
   Networks intends to disclose those patents and license them on
   reasonable and non-discriminatory terms.


 10. References

   [1] T. Li, "CPE Based VPNs Using MPLS", draft-li-mpls-vpn-00.txt,
   October 1998.

   [2] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)" draft-
   ietf-idr-bgp4-08.txt, Augest 1998.




Jamieson, et al                                                 [Page 6]

Internet Draft     draft-jamieson-bgp-solicit-00.txt       November 1998


   [3] T. Bates, R. Chandra, "BGP Route Reflection An Alternative to
   Full Mesh IBGP", RFC 1966, June 1996

   [4] E. Rosen, Y. Rekhter "BGP/MPLS VPNs", draft-rosen-vpn-mpls-
   00.txt, November 1998.

 11. Author's Address

   Dwight Jamieson
   Nortel Networks, Ltd.
   PO Box 3511 Station C
   Ottawa ON K1Y 4H7
   Canada
   Email: djamies@nortelnetworks.com

   Rong Wang
   Nortel Networks, Ltd.
   PO Box 3511 Station C
   Ottawa ON K1Y 4H7
   Canada
   Email: rwang@nortelnetworks.com






























Jamieson, et al                                                 [Page 7]