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

Network Working Group                              Rahul Aggarwal
Internet Draft                                     Chaitanya Kodeboyina
Expiration Date: January 2005                      Juniper Networks


                        Preserving BGP Next-Hops

               draft-raggarwa-bgp-nexthop-rewrite-00.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. 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-00.txt                       [Page 1]

Internet Draft  draft-raggarwa-bgp-nexthop-rewrite-00.txt      July 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-00.txt                       [Page 2]

Internet Draft  draft-raggarwa-bgp-nexthop-rewrite-00.txt      July 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 new
   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 new 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 new
   BGP original next hop attribute MUST not be rewritten by BGP speakers
   that readvertise the NLRI. The address family of next hop address
   carried in the original next hop attribute is derived in the same way
   as that of the next hop address in the NEXT_HOP or MP_REACH_NLRI
   attribute.

   The BGP speakers that receive the NLRI advertisments can use the new
   original 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 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.


3. Security Considerations

   Security considerations discussed in [BGP] apply to this document.


4. IANA Considerations

   This document introduces a new BGP optional transitive attribute.
   The type code for this attribute has to be assigned by IANA.














draft-raggarwa-bgp-nexthop-rewrite-00.txt                       [Page 3]

Internet Draft  draft-raggarwa-bgp-nexthop-rewrite-00.txt      July 2004


5. Acknowledgments

   Many thanks to Yakov Rekhter for helping formulate and discussing the
   mechanisms described in this document.


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


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







draft-raggarwa-bgp-nexthop-rewrite-00.txt                       [Page 4]

Internet Draft  draft-raggarwa-bgp-nexthop-rewrite-00.txt      July 2004


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.


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.














draft-raggarwa-bgp-nexthop-rewrite-00.txt                       [Page 5]

Internet Draft  draft-raggarwa-bgp-nexthop-rewrite-00.txt      July 2004


10. Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.















































draft-raggarwa-bgp-nexthop-rewrite-00.txt                       [Page 6]