Internet DRAFT - draft-nalawade-l3vpn-bgp-connector

draft-nalawade-l3vpn-bgp-connector









Network Working Group                                   Gargi Nalawade
Internet Draft                                          Ruchi Kapoor
October 2005                                            David Ward
                                                        Cisco Systems



                        BGP Connector Attribute
               draft-nalawade-l3vpn-bgp-connector-00.txt




1. Status of this Memo


   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

2. Copyright Notice

   Copyright (C) The Internet Society (2005).  All Rights Reserved.

3. Abstract

   In the case of BGP AFIs such as IPv6 unicast or VPNv4 unicast, it is
   possible for the data traffic intended for the NLRIs of that
   AFI/SAFI, to be forwarded over an underlying tunnel. The tunnel may
   be to a PE or to a Tunnel Concentrator or a Tunnel Broker. Both will
   be referred to as Tunnel endpoints. In this document an egress router



draft-nalawade-l3vpn-bgp-connector-00.txt                               [Page 1]





Internet Draft draft-nalawade-l3vpn-bgp-connector-00.txt            October 2005


   refers to the egress point of the Tunnel and an ingress router refers
   to the ingress point of the tunnel.

   The discovery of the Tunnel endpoint and the corresponding tunnel
   encapsulation information may be done out of band, either by static
   configuration, or through a number of different mechanisms.

   There is a need to be able to indicate with the BGP update for a
   given NLRI, the Tunnel endpoint to be used for forwarding data
   traffic to that NLRI destination.

   This document defines a new BGP attribute called the 'Connector
   Attribute' which would convey the information about the Tunnel
   endpoint - the Tunnel Identifier, the Tunnel endpoint address.

4. Introduction

   When data traffic needs to be tunneled through an ISP core, multiple
   tunneling types can be used (MPLS LSPs, IPsec, L2TPv3,...). The
   establishment of the tunnels as well as the selection of the tunnel
   type(s) to be used from an ingress router to a given egress router
   can be statically controlled by configuration. Alternatively the
   tunneling capabilities and preferences as well as the individual
   tunnel attributes [BGP-TUN] can be dynamically discovered, and in
   turn dynamically established, via various mechanisms such as the BGP
   IPv4/IPv6 Tunnel SAFI [BGP-TUN-SAFI] or IGP based discovery of TE
   tunnels [IGP-TE].

   In some cases, the same tunnel can be used for all NLRIs advertised
   by the egress router. The tunnel can then be selected by the ingress
   router based on its local configuration as well as the information
   that may have been advertised by the egress router about tunneling
   capabilities and preferences for example via [BGP-TUN-SAFI].

   In other cases, different NLRIs may need to be carried over different
   tunnels.  For example, some NLRIs may require transport over IPsec
   tunnels while the other NLRIs may be more efficiently transported
   without IPsec protection over MPLS LSPs. In these cases there is a
   requirement for the egress router to advertise which tunnel ought to
   be used for a particular set of NLRIs. The ingress router needs an
   indication in the BGP update for these NLRIs, as to which tunnel to
   use to reach the egress router. This indication is provided by the
   Connector Attribute which is carried in the BGP AFI/SAFI updates (for
   AFIs such as IPv4 Unicast, VPNv4 unicast etc.)  along with the NLRIs
   for that AFI/SAFI. The Connector attribute indicates the Tunnel-ID
   and Tunnel endpoint address.





draft-nalawade-l3vpn-bgp-connector-00.txt                               [Page 2]





Internet Draft draft-nalawade-l3vpn-bgp-connector-00.txt            October 2005


5. Connector Attribute

   An Optional Transitive Connector attribute is being defined. This
   attribute is meant to transport the Tunnel endpoint Identifier and
   IPv4/6 address to the remote peer.

   The attribute contains one or more tuples of the form :


           0                   1
           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          | Flags |        Type           |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                               |
          |  Value (as specified by Type) |
          |                               |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   where :

   Flags: The first 4 bits are flag bits.
          The leftmost bit indicates whether the Tunnel endpoint is
          IPv4 or IPv6. If the bit is not set it indicates IPv4 and
          if the bit is set, it indicates IPv6.

   Type : indicates the format of the value field.

   Value : is a field as defined by the Type.

   Following Types are being defined :

   Type 1 : indicates that the value contains an IPv4 address of the
            egress router.

   Type 2 : indicates that the value is of the format
            Tunnel-ID:Tunnel endpoint address


          +--------------------------------+
          |  Tunnel Identifier (2 octets)  |
          +--------------------------------+
          |  Tunnel endpoint address       |
          |                                |
          +--------------------------------+





draft-nalawade-l3vpn-bgp-connector-00.txt                               [Page 3]





Internet Draft draft-nalawade-l3vpn-bgp-connector-00.txt            October 2005


      where,

      Tunnel-ID: is a 2 octet Identifier that uniquely identifies a
                 Tunnel on the advertising BGP router

      Tunnel endpoint: is the IPv4/6 address of the Tunnel endpoint.

   Type 3 : indicates that the value if of the format          Multicast
   Tree Identifier:Tunnel endpoint address


          +--------------------------------+
          |  Tree Identifier (2 octets)    |
          +--------------------------------+
          |  Tunnel endpoint address       |
          |                                |
          +--------------------------------+


      where,

      Tree-ID: is a 2 octet Identifier that uniquely identifies a
                 Multicast Tree on the advertising BGP router

      Tunnel endpoint: is the IPv4/6 address of the Multicast Tree
      endpoint.

   The attribute may contain one or more tuples.

8. Operation

   Let us consider the case when an ingress router receives a BGP update
   for NLRIs which will receive data traffic (Eg. IPv4/6
   unicast/multicast, VPNv4/6 etc). If this update contains a Connector
   attribute carrying a Type, Tunnel-ID and Tunnel endpoint address, the
   ingress router will use this information in the following manner :

   The Tunnel/Tree-ID and the Tunnel endpoint address will be used to
   lookup the appropriate tunnel in the Tunnel database to establish
   data forwarding through this Tunnel. Data traffic for the NLRIs
   carried in this BGP update will now be forwarded through this Tunnel.

   The Tunnels themselves will be established by the respective Tunnel
   protocols (Eg. mGRE, IPSec, L2TP etc).

   As an example, if the BGP Tunnel SAFI is the mechanism used to
   discover the Tunnels, then the Tunnel-ID:Tunnel endpoint address will
   be the NLRI carried by the BGP Tunnel SAFI [BGP-TUN-SAFI] updates.



draft-nalawade-l3vpn-bgp-connector-00.txt                               [Page 4]





Internet Draft draft-nalawade-l3vpn-bgp-connector-00.txt            October 2005


   The Tunnel encapsulations will be carried in the BGP Tunnel attribute
   [BGP-TUN] accompanying the BGP Tunnel SAFI update.

   On the other hand, if IGP-based discovery of TE tunnels [IGP-TE], the
   mechanism used to discover TE tunnels, then the Tunnel-ID and Tunnel
   endpoint address will identify the TE tunnel discovered through this
   mechanism.

   Similarly this applies to other out of band Tunnel discovery
   mechanisms as well which includes static configuration.

9. Applicability Statement

9.1. VPNv4 unicast traffic over a Tunnel

   If VPNv4 unicast traffic has to be tunneled through an ISP core
   instead of being MPLS switched as per RFC 2547, then the ingress PE
   needs to know what Tunnel to connect to. The Tunnel encapsulation
   itself could be statically configured or discovered through various
   mechanisms such as IGP based discovery of TE tunnels [IGP-TE] or a
   BGP Tunnel SAFI [BGP-TUN-SAFI].

   If an ingress PE receives a BGP update for the VPNv4 prefix with a
   Connector attribute, it would be able to connect to the appropriate
   Tunnel. Using the Tunnel-ID and Tunnel endpoint address, the
   Connector attribute will indicate which Tunnel is to be used to reach
   the VPNv4 destination.

9.2. MVPN traffic over a default MDT Tunnel

   A Multicast tunnel is setup between the PEs in one or more VPN-
   Providers networks. Over the Multicast tunnel we create PIM
   neighbors. The IP address of the PIM neighbor that is seen over the
   Multicast tunnel depends on the configured address of the Tunnel
   endpoint. This can either be an unnumbered address from a different
   interface or a configured address on the Tunnel itself. The PE router
   that does an RPF check on a VPN source can find which Tunnel the
   source is on, but may not know what PIM neighbor to target on that
   tunnel. Therefore we need a way to connect the BGP VPNv4 prefix to
   the PIM neighbor on the tunnel to allow the RPF check to succeed.

   Suppose PIM wants to join to a source that is behind another VPN
   site. We do an RPF lookup on the source address in the VPNv4 unicast
   table on this PE. The RPF lookup will return a connected next-hop and
   interface to use to reach the source. The returned next-hop may not
   be the neighbor on the Multicast tunnel. This can be due to the
   next-hop being rewritten by BGP Route Reflectors (RR) or crossing
   AS's. Therefore we don't know which PIM neighbor to target as an



draft-nalawade-l3vpn-bgp-connector-00.txt                               [Page 5]





Internet Draft draft-nalawade-l3vpn-bgp-connector-00.txt            October 2005


   upstream neighbor in the PIM join.

   This can be achieved by using the Connector attribute to carry that
   information. The Connector attribute when carried with Type 1, will
   indicate what default MDT tunnel endpoint's IP address is.

9.3. Multicast VPN traffic over Label-switched or other Multicast
Tunnels

   If a BGP Multicast Overlay SAFI [BGP-MOS] is used for signalling
   Multicast Join/Prune Binding information, the downstream PE needs to
   know what Multicast tree built by MLDP or what Tunnel to bind to. The
   Tunnel encapsulation information itself could be provided by MLDP
   when Multipoint LSPs are used in the core. Or the Tunnel
   encapsulation could be provided by TE, or through the BGP Tunnel SAFI
   [BGP-TUN-SAFI]. Either ways, the downstream PE needs to know which
   Tunnel to connect to in order to receive a Multicast stream
   corresponding to a given PIM Join.

   This can be achieved by the Upstream PE sending the Tunnel/P-MP LSP
   binding information through the Connector attribute.

10. Security Considerations

   This extension to BGP does not change the underlying security issues.

11. Acknowledgements

   The authors would like to thank Arjun Sreekantaiah, Francois Le
   Faucher, Eric Rosen and Scott Wainner for their feedback, review and
   comments.

12. Normative References

   [BGP-4]  Rekhter, Y. and T. Li (editors), "A Border Gateway Protocol
   4 (BGP-4)", Internet Draft draft-ietf-idr-bgp4-26.txt, April 2005.

   [BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with
   BGP-4", draft-ietf-idr-rfc2842bis-02.txt, April 2002.

   [BGP-TUN] Kapoor R., Nalawade G., "BGPv4 Tunnel Encapsulation
   Attribute", Oct 2005, <draft-kapoor-nalawade-bgp-ssa-04.txt>, Work in
   Progress.

   [BGP-TUN-SAFI] Nalawade G., Kapoor R., Tappan T., Wainner S. "BGPv4
   Tunnel SAFI", October 2005, <draft-nalawade-kapoor-bgp-tunnel-safi-
   04.txt>, Work in Progress.




draft-nalawade-l3vpn-bgp-connector-00.txt                               [Page 6]





Internet Draft draft-nalawade-l3vpn-bgp-connector-00.txt            October 2005


   [BGP-MOS] Nalawade G., Bhaskar N., Mehta P. "Multicast PE-PE
   Signaling using BGP", October 2005, draft-nalawade-bgp-mcast-
   signaling-00.txt, Work in Progress.

   [MULTI-BGP] Bates et al, Multiprotocol Extensions for BGP-4, draft-
   ietf-idr-rfc2858bis-02.txt, work in progress.

   [IGP-TE] Vasseur J., Psenak P., Yasukawa S., "OSPF MPLS Traffic
   Engineering Capabilities", Feb 2004, Work in Progress.

13. Author's Addresses

   Gargi Nalawade
   170 Tasman Drive
   San Jose, CA, 95134
   E-mail: gargi@cisco.com

   Ruchi Kapoor
   170 Tasman Drive
   San Jose, CA, 95134
   E-mail: ruchi@cisco.com

   David Ward
   408 St Peter Street, Hamm Bldg
   St Paul, MN, 55102
   E-mail: wardd@cisco.com

14. Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology
   described in this document or the extent to which any license
   under such rights might or might not be available; nor does it
   represent that it has made any independent effort to identify any
   such rights.  Information on the procedures with respect to rights
   in RFC documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention
   any copyrights, patents or patent applications, or other
   proprietary rights that may cover technology that may be required



draft-nalawade-l3vpn-bgp-connector-00.txt                               [Page 7]





Internet Draft draft-nalawade-l3vpn-bgp-connector-00.txt            October 2005


   to implement this standard.  Please address the information to the
   IETF at ietf-ipr@ietf.org.


15. Full Copyright Statement

   Copyright (C) The Internet Society (2005). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights."

   "This document and the information contained herein are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

16. Expiration Date

   This memo is filed as <draft-nalawade-l3vpn-bgp-connector-00.txt>, and
   expires April, 2006.





























draft-nalawade-l3vpn-bgp-connector-00.txt                               [Page 8]