INTERNET-DRAFT Peter Kao Network Working Group IP Infusion, Inc. Intended Status: Standards Track Expiration Date: July 9, 2011 January 9, 2011 Carrying Path Binding Information in BGP-4 draft-kao-path-binding-bgp4-00.txt Abstract When BGP is used to distribute a route, it can also be used to distribute a Link Layer PATH_NEXT_HOP binding which is mapped to that route such that packets to that network route can be switched directly across an Ethernet switched network. This document specifies the way in which this is done. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and 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 Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Kao Expires July 9, 2011 [Page 1] Internet-Draft draft-kao-path-binding-bgp4-00.txt January 9, 2011 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Overview ................................................... 2 2. Carrying Ethernet Address Mapping Information .............. 3 3. Advertising Multiple Routes to a Destination ............... 4 4. Capability Negotiation ..................................... 4 5. References ................................................. 4 1. Overview When BGP is used to distribute a route, it can also be used to distribute a Link Layer PATH_NEXT_HOP binding that is mapped to that route. This document specifies the way in which this is done. The PATH_NEXT_HOP binding information for a particular network route is piggybacked in the same BGP Update message that is used to distribute the route itself. This can be useful in the following situation: - BGP speakers can peer with each other directly across a switched Ethernet network. Suppose in a IEEE 802.1ad PB (Provider Bridge) or IEEE 802.1ah PBB (Provider Backbone Bridge) Ethernet switched network, edge bridges E1 and E2 are BGP speakers interconnected via core bridges C1 and C2. E2 advertises destination route D along with a PATH_NEXT_HOP binding. If E1 needs to forward an IP packet to destination route D using E2 as BGP next-hop then E1 will simply put route D's PATH_NEXT_ HOP binding in an Ethernet frame encapsulating the IP packet then forwards that Ethernet frame towards E2 over a VLAN transport path with Independent VLAN Learning (IVL) or IEEE 802.1ay PBB-TE capability, and thereby decoupling the actual path an IP packet takes through a network from routing. The PATH_NEXT_HOP binding is essentially used as a link layer next-hop equivalence to the network layer BGP Next Hop. Kao Expires July 9, 2011 [Page 2] Internet-Draft draft-kao-path-binding-bgp4-00.txt January 9, 2011 In the case of a Route Reflector [BGP-RR], piggybacking the PATH_NEXT _HOP binding on the route distribution will also work with the added benefit of better scalability. If the Route Reflector is not on the forwarding path then it need not to be part of the switched Ethernet network. PATH_NEXT_HOP distribution can be piggybacked in the BGP Update message by using the BGP-4 Multiprotocol Extensions attribute [RFC 2283]. The PATH_NEXT_HOP is encoded into the NLRI field of the attribute, and the SAFI ("Subsequent Address Family Identifier") field is used to indicate that the NLRI contains a PATH_NEXT_HOP. A BGP speaker may not use BGP to send PATH_NEXT_HOP to a particular BGP peer unless that peer indicates, through BGP Capability Negotiation, that it can process Update messages with the specified SAFI field. 2. Carrying PATH_NEXT_HOP Binding Information PATH_NEXT_HOP binding information is carried as part of the Network Layer Reachability Information (NLRI) in the Multiprotocol Extensions attributes. The AFI indicates, as usual, the address family of the associated route. The fact that the NLRI contains a PATH_NEXT_HOP is indicated by using SAFI value 127 [assignment to be confirmed by IANA]. The Network Layer Reachability information is encoded as one or more tuples of the form , whose fields are described below: +----------------------------+ | Length (1 octet) | +----------------------------+ | PATH_NEXT_HOP (6 octets) | +----------------------------+ | Prefix (variable) | +----------------------------+ The use and the meaning of these fields are as follows: a) Length: The Length field indicates the length in bits of the address prefix plus the PATH_NEXT_HOP. b) PATH_NEXT_HOP: The Path_Next_Hop MAC address field carries one Ethernet path next-hop MAC address. Each MAC address is encoded as 48-bit IEEE 802 MAC address. Kao Expires July 9, 2011 [Page 3] Internet-Draft draft-kao-path-binding-bgp4-00.txt January 9, 2011 c) Prefix: The Prefix field contains address prefixes followed by enough trailing bits to make the end of the field fall on an octet boundary. Note that the value of trailing bits is irrelevant. As opposed to the Network Layer BGP Next Hop, the PATH_NEXT_HOP is used to identify a Link Layer Next Hop for the routes distributed in a NLRI. One of the usage of PATH_NEXT_HOP is in BGP/PB IP VPN [BGP- PB-VPN] and BGP/PBB IP VPN [BGP-PBB-VPN]. 3. Advertising Multiple Routes to a Destination A BGP speaker may maintain (and advertise to its peers) more than one route to a given destination, as long as each such route has its own PATH_NEXT_HOP. The encoding described above allows a single BGP Update message to carry multiple routes, each with its own PATH_NEXT_HOP. In the case where a BGP speaker advertises multiple routes to a destination, if a route is withdrawn, only the corresponding route with the corresponding PATH_NEXT_HOP is withdrawn. If a route is withdrawn, and no PATH_NEXT_HOP is specified at the time of withdrawal, then only the corresponding non-PATH_NEXT_HOP route is withdrawn; the PATH_NEXT_HOP routes are left in place. 4. Capability Negotiation A BGP speaker that uses Multiprotocol Extensions to carry PATH_NEXT_ HOP binding information should use the Capabilities Optional Parameter, as defined in [BGP-CAP], to inform its peers about this capability. The MP_EXT Capability Code, as defined in [BGP-MP], is used to negotiate the (AFI, SAFI) pairs available on a particular connection. A BGP speaker should not advertise this capability to another BGP speaker unless there is a Ethernet switched connectivity between the two speakers. A BGP speaker that is capable of handling multiple routes to a destination (as described above) should use the Capabilities Optional Parameter, as defined in [BGP-CAP], to inform its peers about this capability. The value of this capability is TBD. 5. References [BGP-4] RFC 1771, "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter, T. Li, 3/95 Kao Expires July 9, 2011 [Page 4] Internet-Draft draft-kao-path-binding-bgp4-00.txt January 9, 2011 [BGP-CAP] "Capabilities Negotiation with BGP-4", R. Chandra, J. Scudder, draft-ietf-idr-bgp4-cap-neg-04.txt, 9/99 [BGP-MP] RFC 2283, "Multiprotocol Extensions for BGP-4", T. Bates, R. Chandra, D.Katz, Y. Rekhter, 2/98 [BGP-RR] RFC 1966, "BGP Route Reflection: An alternative to full mesh IBGP", T. Bates, R. Chandra, 6/96. [BGP-PB-VPN] Kao, P., "BGP/PB IP Virtual Private Networks (VPNs)", draft-kao-pb-l3vpn-00.txt, January 2011. [BGP-PBB-VPN] Kao, P., "BGP/PBB IP Virtual Private Networks (VPNs)", draft-kao-pbb-l3vpn-00.txt, January 2011. Acknowledgments This documents is heavily based on RFC 4364, whose authors - E. Rosen and Y. Rekhter - are cordially acknowledged. Author's Addresses Peter Kao IP Infusion, Inc. 1188 East Argues Avenue Sunnyvale, CA 94085, USA Email: peterk@ipinfusion.com Kao Expires July 9, 2011 [Page 5]