One document matched: draft-raggarwa-bgp-nexthop-rewrite-01.txt

Differences from draft-raggarwa-bgp-nexthop-rewrite-00.txt

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 <AFI, SAFI> 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]