[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

Network Working Group                                          S. Zhuang
Internet-Draft                                                     Z. Li
Intended status: Standards Track                                 L. Yong
Expires: April 21, 2016                              Huawei Technologies
                                                        October 19, 2015


             BGP Extensions for Enhanced VPN Auto Discovery
            draft-zhuang-bess-enhanced-vpn-auto-discovery-00

Abstract

   All kinds of VPN technologies have been widely deployed to bear
   different services.  As new applications develop, there proposes the
   requirement of auto-discovery of Layer 3 Virtual Private Network
   (L3VPN) and enhanced auto-discovery requirements for other VPN
   technologies which already have the auto-discovery mechanisms.  This
   document identifies the possible applications and these auto-
   discovery requirements.  Accordingly this document defines a new BGP
   NLRI, called the BGP-VPN-INSTANCE NLRI to satisfy the requirement of
   auto-discovery of BGP VPN instance and a new type of the extended
   community, called the Import Route Target which can be applied for
   auto-discovery mechanisms of multiple VPN technologies.

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

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 April 21, 2016.





Zhuang, et al.           Expires April 21, 2016                 [Page 1]


Internet-Draft          BGP Extensions For VPN AD           October 2015


Copyright Notice

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminologies . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Requirements of VPN Auto-Discovery  . . . . . . . . . . . . .   3
     3.1.  Centralized Traffic Optimization  . . . . . . . . . . . .   3
     3.2.  Label/Segment Allocation for VPN Instance . . . . . . . .   3
   4.  IRT Extended Community  . . . . . . . . . . . . . . . . . . .   4
   5.  BGP Extensions for L3VPN Auto-Discovery . . . . . . . . . . .   4
     5.1.  BGP-VPN-INSTANCE SAFI . . . . . . . . . . . . . . . . . .   4
     5.2.  BGP-VPN-INSTANCE NLRI . . . . . . . . . . . . . . . . . .   5
       5.2.1.  VPN Membership A-D Route  . . . . . . . . . . . . . .   6
     5.3.  Procedures  . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   7
     10.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   All kinds of VPN technologies have been widely deployed to bear
   different services.  As new applications develop, there proposes the
   requirement of auto-discovery of Layer 3 Virtual Private Network
   (L3VPN) [RFC4364] and enhanced auto-discovery requirements for other
   VPN technologies which already have the auto-discovery mechanisms.
   This document identifies the possible applications and these auto-
   discovery requirements.  Accordingly this document defines a new BGP
   NLRI, called the BGP-VPN-INSTANCE NLRI to satisfy the requirement of
   auto-discovery of BGP VPN instance and a new type of the extended



Zhuang, et al.           Expires April 21, 2016                 [Page 2]


Internet-Draft          BGP Extensions For VPN AD           October 2015


   community, called the Import Route Target which can be applied for
   auto-discovery mechanisms of multiple VPN technologies.

2.  Terminologies

   This document uses the terminologies defined in [RFC4026]:

   ERT: Export Route Target

   IRT: Import Route Target

   PE: Provider Edge

   RD: Route Distinguisher

   VRF: Virtual Routing and Forwarding

   VPN A-D: VPN Auto-Discovery

3.  Requirements of VPN Auto-Discovery

3.1.  Centralized Traffic Optimization

   As the development of central controlled application such as PCE-
   initiated LSP[I-D.ietf-pce-pce-initiated-lsp]and PCE-initiated P2MP
   LSP[I-D.palle-pce-stateful-pce-initiated-p2mp-lsp], PCE can be used
   to initiate setup of RSVP-TE LSP or P2MP LSP for the purpose of
   traffic optimization.  In order to support such applications, the
   controller should learn the relationship of unicast VPN instances or
   multicast VPN instances distributed on different PEs.  According to
   the existing auto-discovery mechanism of VPN technologies such as
   EVPN[RFC7432] or MVPN[RFC6514], the A-D routes are always advertised
   with the Export Route Target (ERT).  The ingress PE can use the
   Import Route Target (IRT) of local MVPN/EVPN instance to match the
   route target advertised with the NLRI to determine the relationship
   of these VPN instances.  But the controller which can be used as the
   RR of VPN routes cannot learn the relationship of VPN instances since
   the Import Route Target information is not advertised with these A-D
   routes.  In order to support such applications the IRT should be
   carried with A-D routes.

3.2.  Label/Segment Allocation for VPN Instance

   [I-D.li-mpls-global-label-usecases] propose the usecases of label
   allocation for unicast VPN or multicast VPN instance.
   [I-D.li-spring-segment-path-programming] propose the usecases of
   segment allocation for steering traffic.  In order to support such
   applications the PEs needs to learn the relationship of VPN instances



Zhuang, et al.           Expires April 21, 2016                 [Page 3]


Internet-Draft          BGP Extensions For VPN AD           October 2015


   distributed on other PEs.  For L3VPN [RFC4364] there is no auto-
   discovery mechanism of BGP VPN instance.  In order to support such
   applications, auto-discovery mechanism should be introduced for
   L3VPN.

4.  IRT Extended Community

   This document defines a new type of the extended community, called as
   Import Route Target.  This extended community is a new transitive
   extended community with the Sub-Type field is TBD.

   The IANA registry of BGP Extended Communities clearly identifies
   communities of specific formats: "Two-octet AS Specific Extended
   Community" [RFC4360], "Four-octet AS Specific Extended Community"
   [RFC5668], and "IPv4 Address Specific Extended Community" [RFC4360].
   Route Targets [RFC4360] extended community identify this format in
   the high-order (Type) octet of the Extended Community.  Import Route
   Target extended community will reuses the same mechanism.

   This document defines the following IRT Extended Communities:

+------+--------+--------------------+-------------------------------------+
| Type |Sub-Type| Extended Community | Encoding                            |
+------+--------+--------------------+-------------------------------------+
| 0x00 | TBD    | AS-2byte IRT       | 2-octet AS, 4-octet Value           |
| 0x01 | TBD    | IPv4 IRT           | 4-octet IPv4 Address, 2-octet Value |
| 0x02 | TBD    | AS-4byte IRT       | 4-octet AS, 2-octet Value           |
+------+--------+--------------------+-------------------------------------+

                     Figure 1 IRT Extended Communities


   The IRT Extended Community can be used for MVPN[RFC6514],
   L3VPN[RFC4364], EVPN[RFC7432], BGP-based VPLS[RFC4761], and BGP-AD-
   based VPLS[RFC6074] etc.  The existing auto-discovery mechanisms of
   these VPN technologies always carry the ERT extended community.
   According to the requirements of applications, the IRT extended
   community SHOULD be able to be carried with different A-D routes.
   The local policy can be used to control the distribution of IRT
   information which is out of scope of this document.

5.  BGP Extensions for L3VPN Auto-Discovery

5.1.  BGP-VPN-INSTANCE SAFI

   The BGP Multiprotocol Extensions [RFC4760] allow BGP to carry routes
   from multiple "address families".  In this document a new Subsequent




Zhuang, et al.           Expires April 21, 2016                 [Page 4]


Internet-Draft          BGP Extensions For VPN AD           October 2015


   Address Family is introduced, called "BGP-VPN-INSTANCE Sub Address
   Family" uses a specific BGP-VPN-INSTANCE-SAFI (TBD).

   This document also defines a new BGP NLRI, called the BGP-VPN-
   INSTANCE NLRI to support the BGP VPN instance auto-discovery.  BGP-
   VPN-INSTANCE MP_REACH_NLRI and MP_UNREACH_NLRI (shown in the figure 1
   and figure 2) are formatted as described in [RFC4760].

   +-------------------------------------------------------+
   | Address Family Identifier (2 octets): 1/2/25          |
   +-------------------------------------------------------+
   | Subsequent AFI (1 octet): BGP-VPN-INSTANCE-SAFI (TBD) |
   +-------------------------------------------------------+
   | Length of Next Hop (1 octet)                          |
   +-------------------------------------------------------+
   | Next Hop (variable)                                   |
   +-------------------------------------------------------+
   | Reserved (1 octet)                                    |
   +-------------------------------------------------------+
   | BGP-VPN-INSTANCE NLRI (variable)                      |
   +-------------------------------------------------------+

           Figure 2 BGP-VPN-INSTANCE MP_REACH_NLRI

   +-------------------------------------------------------+
   | Address Family Identifier (2 octets): 1/2/25          |
   +-------------------------------------------------------+
   | Subsequent AFI (1 octet): BGP-VPN-INSTANCE-SAFI (TBD) |
   +-------------------------------------------------------+
   |  BGP-VPN-INSTANCE NLRI (variable)                     |
   +-------------------------------------------------------+

         Figure 3  BGP-VPN-INSTANCE MP_UNREACH_NLRI

5.2.  BGP-VPN-INSTANCE NLRI

   The following is the format of the BGP-VPN-INSTANCE NLRI.

   +---------------------------------------------------+
   | Route Type (1 octet)                              |
   +---------------------------------------------------+
   | Length (1 octet)                                  |
   +---------------------------------------------------+
   | Route Type Specific (variable)                    |
   +---------------------------------------------------+

          Figure 4 BGP-VPN-INSTANCE NLRI




Zhuang, et al.           Expires April 21, 2016                 [Page 5]


Internet-Draft          BGP Extensions For VPN AD           October 2015


   The Route Type field defines the encoding of the rest of BGP-VPN-
   INSTANCE NLRI (Route Type specific BGP-VPN-INSTANCE NLRI).

   The Length field indicates the length in octets of the Route Type
   specific field of the BGP-VPN-INSTANCE NLRI.

   This document defines the following Route Types for BGP-VPN-INSTANCE
   routes:

   -- Type 1: VPN Membership A-D Route

5.2.1.  VPN Membership A-D Route

   VPN Membership A-D Route is utilized for VPN Membership Auto-
   Discovery between PEs.

   Its format is defined as following diagram:

   +--------------------------------------------------+
   | Local Router's IP Address (variable)             |
   +--------------------------------------------------+
   | RD (8 octets)                                    |
   +--------------------------------------------------+

           Figure 5 VPN Membership A-D Route


   a) Local Router's IP Address: Advertising PE's IPv4/IPv6 address.

   b) RD: RD of one VRF on advertising PE, encoded as described in
   [RFC4364].

5.3.  Procedures

   For every PE, it needs to process all its VRF configuration and
   generate one VPN Membership A-D Route for each VRF respectively.
   Local Router's IP Address field MUST filled with the Advertising
   Router's IP address.  RD field MUST be filled with the VRF's RD
   value.

   All ERTs of the VRF MUST be carried in BGP Update's RT Extended
   Community Path Attribute with the Membership A-D Route for the VRF.
   According to the requirement of different applications, all IRTs of
   the VRF SHOULD be able to be carried in BGP Update's IRT Extended
   Community Path Attribute with the VPN Membership A-D Route for the
   VRF.





Zhuang, et al.           Expires April 21, 2016                 [Page 6]


Internet-Draft          BGP Extensions For VPN AD           October 2015


   If a VRF is created, then its corresponding VPN Membership A-D Route
   MUST be generated and advertised.

   If the VRF whose VPN Membership A-D Route has been advertised is
   deleted, then the VPN Membership A-D Route Withdraw message MUST be
   generated and advertised.

   If IRTs or ERTs of the VRF whose VPN Membership A-D Route has been
   advertised are changed, then a VPN Membership A-D Route Update with
   same Prefix and latest IRTs or ERTs MUST be advertised.

   When the receiving PE receives VPN Membership A-D Route, VPN
   relationship matching MUST be checked with IRTs carried in VPN
   Membership A-D Route and ERTs of each Local VRF.

   When the central controller receives VPN Membership A-D Route, VPN
   relationship matching MUST be checked with IRTs and ERTs carried in
   VPN Membership A-D Routes of different VPN instances.

6.  Contributors

   The following people have substantially contributed to the solution
   and to the editing of this document:.

   Hui Ni
   Huawei
   Email: nihui@huawei.com

7.  IANA Considerations

   TBD.

8.  Security Considerations

   TBD

9.  Acknowledgements

   The authors would like to thank Shuanglong Chen, Eric Wu for their
   contributions to this work.

10.  References

10.1.  Normative References







Zhuang, et al.           Expires April 21, 2016                 [Page 7]


Internet-Draft          BGP Extensions For VPN AD           October 2015


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <http://www.rfc-editor.org/info/rfc4271>.

   [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
              Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
              February 2006, <http://www.rfc-editor.org/info/rfc4360>.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
              2006, <http://www.rfc-editor.org/info/rfc4364>.

   [RFC4365]  Rosen, E., "Applicability Statement for BGP/MPLS IP
              Virtual Private Networks (VPNs)", RFC 4365,
              DOI 10.17487/RFC4365, February 2006,
              <http://www.rfc-editor.org/info/rfc4365>.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              DOI 10.17487/RFC4760, January 2007,
              <http://www.rfc-editor.org/info/rfc4760>.

   [RFC4761]  Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
              LAN Service (VPLS) Using BGP for Auto-Discovery and
              Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
              <http://www.rfc-editor.org/info/rfc4761>.

   [RFC5668]  Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS
              Specific BGP Extended Community", RFC 5668,
              DOI 10.17487/RFC5668, October 2009,
              <http://www.rfc-editor.org/info/rfc5668>.

   [RFC6074]  Rosen, E., Davie, B., Radoaca, V., and W. Luo,
              "Provisioning, Auto-Discovery, and Signaling in Layer 2
              Virtual Private Networks (L2VPNs)", RFC 6074,
              DOI 10.17487/RFC6074, January 2011,
              <http://www.rfc-editor.org/info/rfc6074>.

   [RFC6514]  Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
              Encodings and Procedures for Multicast in MPLS/BGP IP
              VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
              <http://www.rfc-editor.org/info/rfc6514>.



Zhuang, et al.           Expires April 21, 2016                 [Page 8]


Internet-Draft          BGP Extensions For VPN AD           October 2015


   [RFC7432]  Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
              Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
              Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
              2015, <http://www.rfc-editor.org/info/rfc7432>.

10.2.  Informative References

   [I-D.ietf-pce-pce-initiated-lsp]
              Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
              Extensions for PCE-initiated LSP Setup in a Stateful PCE
              Model", draft-ietf-pce-pce-initiated-lsp-04 (work in
              progress), April 2015.

   [I-D.li-mpls-global-label-usecases]
              Li, Z., Zhao, Q., Yang, T., Raszuk, R., and L. Fang,
              "Usecases of MPLS Global Label", draft-li-mpls-global-
              label-usecases-03 (work in progress), October 2015.

   [I-D.li-spring-segment-path-programming]
              Li, Z. and I. Milojevic, "Segment Path Programming (SPP)",
              draft-li-spring-segment-path-programming-00 (work in
              progress), October 2015.

   [I-D.palle-pce-stateful-pce-initiated-p2mp-lsp]
              Palle, U., Dhody, D., Tanaka, Y., Ali, Z., and V. Beeram,
              "PCEP Extensions for PCE-initiated Point-to-Multipoint LSP
              Setup in a Stateful PCE Model", draft-palle-pce-stateful-
              pce-initiated-p2mp-lsp-06 (work in progress), June 2015.

   [RFC6513]  Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
              BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
              2012, <http://www.rfc-editor.org/info/rfc6513>.

Authors' Addresses

   Shunwan Zhuang
   Huawei Technologies
   Huawei Building, No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: jie.dong@huawei.com









Zhuang, et al.           Expires April 21, 2016                 [Page 9]


Internet-Draft          BGP Extensions For VPN AD           October 2015


   Zhenbin Li
   Huawei Technologies
   Huawei Building, No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: lizhenbin@huawei.com


   Lucy Yong
   Huawei Technologies

   Email: lucy.yong@huawei.com






































Zhuang, et al.           Expires April 21, 2016                [Page 10]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/