Internet DRAFT - draft-xu-l3vpn-prefix-constrain

draft-xu-l3vpn-prefix-constrain







Network Working Group                                              X. Xu
Internet-Draft                                                   M. Chen
Intended status: Standards Track                                  Huawei
Expires: July 27, 2014                                  January 23, 2014


         Address Prefix Based VPN Route Distribution Constrain
                   draft-xu-l3vpn-prefix-constrain-00

Abstract

   This document defines MP-BGP procedures that allow BGP speakers to
   exchange VPN route interest information.  This information can be
   used to control VPN route distribution at the granularity of address
   prefix, which is applicable in the context of Virtual Subnet and may
   also be applicable in other BGP/MPLS IP VPN environments.

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).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on July 27, 2014.

Copyright Notice

   Copyright (c) 2014 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
   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.



Xu & Chen                 Expires July 27, 2014                 [Page 1]

Internet-Draft                                              January 2014


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  VPN Route Interest Advertisement  . . . . . . . . . . . . . .   3
   4.  Capability Advertisement  . . . . . . . . . . . . . . . . . .   4
   5.  Operations  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   The Route Target Contrain mechanism defined in [RFC4684] allows a BGP
   speaker to control VPN route distribution by using the received Route
   Target membership information.  However, in some network environments
   where the amount of VPN routes is too large, it's usually expected to
   control the VPN route distribution at a finer granulurity (e.g., VPN
   address prefix).  In other word, it's expected to support the pull-
   mode for VPN route distribution at a finer granurility.

   This document builds on the concept of on-demand VPN route
   distribution asdescribed in [RFC4684] and defines new procedures that
   allow BGP speakers to exchange VPN route interest information.  This
   information can be used to control VPN route distribution at the
   granularity of address prefix.  This fine-grained VPN route
   distribution control is applicable in the context of Virtual Subnet
   [I-D.xu-l3vpn-virtual-subnet] and may also be applicable in other BGP
   /MPLS IP VPN [RFC4364] environments.

1.1.  Requirements Language

   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 [RFC2119].

2.  Terminology

   This memo makes use of the terms defined in [RFC2858] and [RFC4364].







Xu & Chen                 Expires July 27, 2014                 [Page 2]

Internet-Draft                                              January 2014


3.  VPN Route Interest Advertisement

   VPN Route Interest NLRI is advertised in BGP UPDATE messages using
   the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC2858].  The
   [AFI, SAFI] value pair for VPNv4 Route Interest NLRI is (AFI=1,
   SAFI=TBD1), and the [AFI, SAFI] value pair for VPNv6 Route Interest
   NLRI is (AFI=2, SAFI=TBD1).  The Next Hop field of MP_REACH_NLRI
   attribute shall be interpreted as an IPv4 address whenever the length
   of NextHop address is 4 octets, and as a IPv6 address whenever the
   length of the NextHop address is 16 octets.  The NLRI field in the
   MP_REACH_NLRI and MP_UNREACH_NLRI contains the IPv4 or IPv6 address
   prefix part of a VPN address prefix which is interesting to the
   originator of such NLRI.  In other word, the Route Distinguisher (RD)
   part of that VPN address prefix is not contained.  A Route Target
   extended community is attached to the NLRI to indicate the VPN
   instance that the above IPv4 or IPv6 address prefix belongs to.

   In order to restrict the propagation scope of VPN route interest
   information, the VPN Route Interest NLRI containning a VPN route of a
   particular VPN SHOULD only be propagated to those BGP peers which
   maintain routes for that VPN.  That's to say, the exact propagation
   of the VPN Route Interest NLRI is built upon the discovery of the
   export Route Target membership Information.  Note that the export
   Route Target membership information here is different from the
   (import) Route Target membership information as described in
   [RFC4684], since the former expresses the semantic of "I have VPN
   routes associated with a particular Route Target" while the latter
   expresses the semantic of "I want VPN routes associated with a
   particular Route Target".  To disthguish them from each other, the
   export Route Target membership information SHOULD be conveyed in a
   different NLRI (AFI=1, SAFI=TBD2) other than that (AFI=1, SAFI=132)
   for conveying the (import) Route Target membership information.  The
   advertisement procedure for export Route Target membership
   information is the same as that for the (import) Route Target
   membership information except that the former is used for controlling
   the propagation of VPN Route Interest NLRIs while the latter is used
   for controlling the propagation of VPN routes.  Of course, the export
   Route Target membership informaiton can also be used to control the
   propagation of the (import) Route Target membership information if
   desired.  In this way, the (import) Route Target membership
   information expressing the semantic of "I want VPN route of a given
   Route Target X" would only be propagated to those BGP peers who have
   indicated that they have VPN routes for Route Target X by advertising
   the export Route Target membership information.

   A VPN Route Interest NLRI SHOULD only be advertised to a peer that
   participates in the exchange of VPN route interest information if
   that peer has advertised either the default export Route Target



Xu & Chen                 Expires July 27, 2014                 [Page 3]

Internet-Draft                                              January 2014


   membership NLRI or a export Route Target membership NLRI containing
   any of the targets contained in the extended communities attribute of
   the VPN route interest NRLI in question.  In other word, the export
   Route Target membership information is used to restrict the
   distribution of the VPN route interest information (at the Route
   Target granularity) which in turn is used to control the VPN route
   distribution (at the address prefix granularity).  The address
   prefix-based VPN route distribution control based upon the VPN Route
   Interest NRLIs could be used together with the Route Target-based
   route distribution control based upon the (import) Route Target
   Membership NLRIs.  For instance, a BGP speaker may want its peer to
   send all routes for VPN red and some particular routes for VPN blue.
   It is NOT RECOMMENDED to propagate a VPN Route Interest NLRI
   associated with a given Route Target towards a peer to whom an
   "import" Route Target membership NLRI containing the said Route
   Target has been sent before.

4.  Capability Advertisement

   A BGP speaker that wishes to exchange VPN Route Interest information
   MUST use the Multiprotocol Extensions Capability Code, as defined in
   [RFC2858], to advertise the corresponding (AFI, SAFI) pair.  Since
   the exact propagation of the VPN Route Interest Information depends
   on the pre-progagation of the export Route Target membership
   Information, the Capability for the export Route Target membership
   NLRI (AFI=1, SAFI=TBD2) MUST be supported as a prerequisite.

5.  Operations

   A VPN route SHOULD be advertised to a peer that participates in the
   exchange of VPN route interest information if that peer has
   advertised a VPN Route Interest NLRI containing the the same IPv4 or
   IPv6 address prefix as that of the VPN route in question and the
   Route Target of that VPN route is the same as the Route Target
   associated with that VPN Route Interest NLRI.  Note that here the RD
   part of the VPN route SHOULD be ignored when performing the VPN route
   search.  When a BGP speaker receives a BGP UPDATE that advertises or
   withdraws a given VPN Route Interest NLRI, it SHOULD examine the RIB-
   OUTs of VPN NLRIs and re-evaluate the advertisement status of routes
   that match the VPN Route Interest NLRI in question.  A BGP speaker
   SHOULD generate the minimum set of BGP VPN route updates
   (advertisements and/or withdrawls) necessary to transition between
   the previous and current state of the route distribution graph that
   is derived from VPN Route Interest information.  As a hint that
   initial VPN Route Interest Information exchange is complete,
   implementations SHOULD generate an End-of-RIB marker, as defined in
   [RFC4724], for the VPN Route Interest information (AFI=1 or 2,
   SAFI=TBD1), regardless of whether graceful-restart is enabled on the



Xu & Chen                 Expires July 27, 2014                 [Page 4]

Internet-Draft                                              January 2014


   BGP session.  This allows the receiver to know when it has received
   the full contents of the peer's VPN Route Interest information.  The
   exchange of VPN NLRI SHOULD follow the receipt of the End-of-RIB
   markers.  If a BGP speaker chooses to delay the advertisement of BGP
   VPN route updates until it receives this End-of-RIB marker, it MUST
   limit that delay to an upper bound.  By default, a 60 second value
   SHOULD be used.  Similarly, the exchange of VPN Route Interest NLRI
   SHOULD folow the receipt of the End-of-RIB markers for the export
   Route Target Membership NLRI (AFI=1, SAFI=TBD2).

6.  Acknowledgements

   The authors would like to thank ... for their comments on this
   document.

7.  IANA Considerations

   The SAFI codes for VPNv4 and VPNv6 Route Interest needs to be
   assigned respectively by the IANA.

8.  Security Considerations

   This document does not introduce any new security risk to the BGP/
   MPLS IP VPN.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2858]  Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
              "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.

   [RFC4684]  Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
              R., Patel, K., and J. Guichard, "Constrained Route
              Distribution for Border Gateway Protocol/MultiProtocol
              Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
              Private Networks (VPNs)", RFC 4684, November 2006.

   [RFC4724]  Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
              Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
              January 2007.







Xu & Chen                 Expires July 27, 2014                 [Page 5]

Internet-Draft                                              January 2014


9.2.  Informative References

   [I-D.xu-l3vpn-virtual-subnet]
              Building, K., Hares, S., Yongbing, F., Jacquenet, C.,
              Boyes, T., and B. Fee, "Virtual Subnet: A L3VPN-based
              Subnet Extension Solution", draft-xu-l3vpn-virtual-
              subnet-02 (work in progress), November 2013.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, February 2006.

Authors' Addresses

   Xiaohu Xu
   Huawei

   Email: xuxiaohu@huawei.com


   Mach Chen
   Huawei

   Email: mach.chen@huawei.com




























Xu & Chen                 Expires July 27, 2014                 [Page 6]