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, , Work in Progress. [BGP-TUN-SAFI] Nalawade G., Kapoor R., Tappan T., Wainner S. "BGPv4 Tunnel SAFI", October 2005, , 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 , and expires April, 2006. draft-nalawade-l3vpn-bgp-connector-00.txt [Page 8]