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]