Network Working Group Rahul Aggarwal Internet Draft Chaitanya Kodeboyina Expiration Date: February 2005 Juniper Networks Preserving Original BGP Next Hops draft-raggarwa-bgp-nexthop-rewrite-01.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. Abstract A BGP speaker uses the NEXT_HOP attribute or the MP_REACH_NLRI attribute to advertise the IP address that should be used as the next hop to the destinations listed in the Network Layer Reachability Information (NLRI). This next hop may be rewritten by other BGP speakers when the NLRI is re-advertised by these speakers. Some applications depend on the original BGP next hop. This document proposes a mechanism to preserve the original BGP next hop. draft-raggarwa-bgp-nexthop-rewrite-01.txt [Page 1] Internet Draft draft-raggarwa-bgp-nexthop-rewrite-01.txt August 2004 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [KEYWORDS]. 1. Motivation A BGP speaker uses the NEXT_HOP attribute [BGP] or the MP_REACH_NLRI attribute [BGP-MULTI] to advertise the IP address that should be used as the next hop to the destinations listed in the NLRI. We call the next hop advertised by the BGP speaker that originates the NLRI as the original BGP next hop. This next hop may be rewritten by other BGP speakers when the NLRI is re-advertised. Some applications depend on the original BGP next hop. One such application is described below as an illustration. There may be other such applications that can make use of the mechanism described in this draft. 1.1. Inter-AS Multicast in BGP-MPLS VPNs One example of an application that depends on the original BGP next hop is multicast in BGP-MPLS VPNs [MVPN-PIM] across multiple Autonomous Systems (AS). [2547] describes three methods for creating inter-AS VPNs: Option A, Option B and Option C. Option B requires EBGP redistribution of labeled VPN-IP routes from the originating AS to the neighboring AS. PEs in the local AS advertise the labeled VPN- IP routes with the next hop set to a local address. This is the same address that is used as the PIM Multicast Tunnel (MT) interface address by the local PE and the PIM neighbor address by the PEs in the neighboring AS [MVPN-PIM]. The BGP next hop of the unicast VPN routes is rewritten in option B at the AS Border Routers (ASBR). Hence when the remote PEs receive the labeled VPN routes the BGP next hop is not the same as the PIM neighbor address. Thus the procedures for determining the PIM RPF neighbor fail as the next hop to reach the multicast source is not a PIM neighbor. draft-raggarwa-bgp-nexthop-rewrite-01.txt [Page 2] Internet Draft draft-raggarwa-bgp-nexthop-rewrite-01.txt August 2004 2. Mechanism To preserve the original BGP next hop this document proposes that the BGP speaker orginating the NLRI use a new BGP optional transitive attribute to advertise the IP address of the original next hop. This is the Original_BGP_Next_Hop attribute. The type code is TBD. The value of this attribute has the following format: +---------------------------------------------------------+ | Address Family Identifier (AFI) (2 octets) | +---------------------------------------------------------+ | Subsequent Address Family Identifier (SAFI) (1 octet) | +---------------------------------------------------------+ | Network Address of Next Hop (variable) | +---------------------------------------------------------+ The Original_BGP_Next_Hop attribute is advertised in addition to the next hop address in the existing NEXT_HOP attribute or the MP_REACH_NLRI attribute. The next hop address in the BGP_Original_Next_Hop attribute is set to the same value as the next hop address in the NEXT_HOP attribute or the MP_REACH_NLRI attribute that is advertised by the BGP speaker originating the NLRI. However the Original_BGP_Next_Hop attribute MUST not be rewritten by BGP speakers that readvertise the NLRI. The Network Layer protocol associated with the Network Address of the next hop is identified by a combination of carried in the attribute. The BGP speakers that receive the NLRI advertisments can use the Original_BGP_Next_Hop attribute to learn the original BGP next hop. This original BGP next hop can then be used by the applications that depend on it. For example in the Inter-AS Option B MVPN application described in section 1.1 of this document the remote PEs can use the original BGP next hop as the next hop to reach the PIM multicast source. The procedures for determining the PIM RPF neighbor will now succeed as the original BGP next hop IP address is the same as the PIM neighbor IP address. draft-raggarwa-bgp-nexthop-rewrite-01.txt [Page 3] Internet Draft draft-raggarwa-bgp-nexthop-rewrite-01.txt August 2004 3. Security Considerations Security considerations discussed in [BGP] apply to this document. 4. IANA Considerations This document introduceds a new BGP optional transitive attribute. The type code for this attribute has to be assigned by IANA. 5. Acknowledgments Many thanks to Yakov Rekhter for helping formulate and discussing the mechanisms described in this document. Thanks to John Scudder and Enke Chen for their comments. 6. References 6.1. Normative References [BGP] Y. Rekhter, T. Li, S. Harres, "A Border Gateway Protocol 4 (BGP-4)", draft-ietf-idr-bgp4-24.txt. [BGP-MULTI] T. Bates et. al., "Multiprotocol Extensions for BGP-4", draft-ietf-idr-rfc2858bis-06.txt [RFC] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2. Informative References [2547] "BGP/MPLS VPNs", Rosen, Rekhter, et. al., September 2003, draft-ietf-l3vpn-rfc2547bis-01.txt [MVPN-PIM] R. Aggarwal, A. Lohiya, T. Pusateri, Y. Rekther, "Base specification for Multicast in BGP/MPLS VPNs", draft-raggarwa- l3vpn-2547-mvpn-00.txt draft-raggarwa-bgp-nexthop-rewrite-01.txt [Page 4] Internet Draft draft-raggarwa-bgp-nexthop-rewrite-01.txt August 2004 7. Author Information Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: rahul@juniper.net Chaitanya Kodeboyina Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: ck@juniper.net 8. Intellectual Property 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 to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. draft-raggarwa-bgp-nexthop-rewrite-01.txt [Page 5] Internet Draft draft-raggarwa-bgp-nexthop-rewrite-01.txt August 2004 9. Full Copyright Statement Copyright (C) The Internet Society (2004). 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 is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 10. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. draft-raggarwa-bgp-nexthop-rewrite-01.txt [Page 6]