< draft-zhuang-bess-enhanced-vpn-auto-discovery-02.txt   draft-zhuang-bess-enhanced-vpn-auto-discovery-03.txt >
INTERNET-DRAFT Shunwan Zhuang INTERNET-DRAFT Shunwan Zhuang
Intended status: Proposed Standard Zhenbin Li Intended status: Proposed Standard Zhenbin Li
Donald Eastlake Donald Eastlake
Huawei Huawei
Lucy Yong Lucy Yong
Independent Independent
Expires: May 5, 2018 November 6, 2018 Expires: November 5, 2019 May 6, 2019
BGP Extensions for Enhanced VPN Auto Discovery BGP Extensions for Enhanced VPN Auto Discovery
draft-zhuang-bess-enhanced-vpn-auto-discovery-02.txt draft-zhuang-bess-enhanced-vpn-auto-discovery-03.txt
Abstract Abstract
A variety of VPN technologies have been widely deployed to bear A variety of VPN technologies have been widely deployed to bear
different services. As new applications develop, a requirement has different services. As new applications develop, a requirement has
been proposed for auto-discovery of Layer 3 Virtual Private Networks been proposed for auto-discovery of Layer 3 Virtual Private Networks
(L3VPN) and enhanced auto-discovery requirements for other VPN (L3VPN) and enhanced auto-discovery requirements for other VPN
technologies that already have basic auto-discovery mechanisms. technologies that already have basic auto-discovery mechanisms.
This document identifies some possible applications of these auto- This document identifies some possible applications of these auto-
discovery requirements and defines a new BGP NLRI, called the BGP- discovery requirements and defines a new BGP NLRI, called the BGP-
VPN-INSTANCE NLRI, to satisfy the requirement for auto-discovery of VPN-INSTANCE NLRI, to satisfy the requirement for auto-discovery of
BGP VPN instances. It also defines a new type of extended community, BGP VPN instances. It also defines a new type of extended community,
called the Import Route Target, which can be applied to auto- called the Import Route Target, which can be applied to auto-
discovery mechanisms of multiple VPN technologies. discovery mechanisms of multiple VPN technologies.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Distribution of this document is unlimited. Comments should be sent Distribution of this document is unlimited. Comments should be sent
to the authors or the BESS working group mailing list: bess@ietf.org. to the authors or the BESS working group mailing list: bess@ietf.org.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 4, line 21 skipping to change at page 4, line 21
AFI: Address Family Identifier AFI: Address Family Identifier
ERT: Export Route Target ERT: Export Route Target
IRT: Import Route Target IRT: Import Route Target
LSP: Label Switched Path LSP: Label Switched Path
NLRI: Network Layer Reachability Information NLRI: Network Layer Reachability Information
P2MP: Point to Multi-Point
PE: Provider Edge PE: Provider Edge
RD: Route Distinguisher RD: Route Distinguisher
VRF: Virtual Routing and Forwarding VRF: Virtual Routing and Forwarding
VPN A-D: VPN Auto-Discovery VPN A-D: VPN Auto-Discovery
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
skipping to change at page 5, line 29 skipping to change at page 5, line 29
the relationship of unicast VPN instances or multicast VPN instances the relationship of unicast VPN instances or multicast VPN instances
distributed on different PEs. According to the existing VPN auto- distributed on different PEs. According to the existing VPN auto-
discovery mechanism for technologies such as EVPN [RFC7432] or MVPN discovery mechanism for technologies such as EVPN [RFC7432] or MVPN
[RFC6514], the A-D routes are always advertised with the Export Route [RFC6514], the A-D routes are always advertised with the Export Route
Target (ERT). The ingress PE can use an Import Route Target (IRT) of Target (ERT). The ingress PE can use an Import Route Target (IRT) of
the local MVPN/EVPN instance to match the route target advertised the local MVPN/EVPN instance to match the route target advertised
with the NLRI to determine the relationship of these VPN instances. with the NLRI to determine the relationship of these VPN instances.
But the controller, which can be used as the route reflector of VPN But the controller, which can be used as the route reflector of VPN
routes, cannot learn the relationship of VPN instances since the routes, cannot learn the relationship of VPN instances since the
Import Route Target information is not advertised with these A-D Import Route Target information is not advertised with these A-D
routes. In order to support such applications the IRT should be routes. In order to support such applications the IRT can be carried
carried with A-D routes. with A-D routes as specified below.
3.2 Label/Segment Allocation for VPN Instance 3.2 Label/Segment Allocation for VPN Instance
[I-D.li-mpls-global-label-usecases] proposes use cases of label [I-D.li-mpls-global-label-usecases] proposes use cases of label
allocation for unicast VPN or multicast VPN instances. [I-D.li- allocation for unicast VPN or multicast VPN instances. [I-D.li-
spring-segment-path-programming] proposes use cases of segment spring-segment-path-programming] proposes use cases of segment
allocation for steering traffic. In order to support such allocation for steering traffic. In order to support such
applications the PEs needs to learn the relationship of VPN instances applications the PEs needs to learn the relationship of VPN instances
distributed on other PEs. For L3VPN [RFC4364] there is no auto- distributed on other PEs. For L3VPN [RFC4364] there is no auto-
discovery mechanism for BGP VPN instances. In order to support such discovery mechanism for BGP VPN instances. In order to support such
applications, an auto-discovery mechanism should be introduced for applications, an auto-discovery mechanism for L3VPN is specified
L3VPN. below.
INTERNET-DRAFT BGP Extensions For VPN AD INTERNET-DRAFT BGP Extensions For VPN AD
4. IRT Extended Community 4. IRT Extended Community
This document defines a new type of transitive extended community, This document defines a new type of transitive extended community,
called as Import Route Target. called as Import Route Target.
The IANA registry of BGP Extended Communities clearly identifies The IANA registry of BGP Extended Communities clearly identifies
communities of specific formats: "Two-octet AS Specific Extended communities of specific formats: "Two-octet AS Specific Extended
Community" [RFC4360], "Four-octet AS Specific Extended Community" Community" [RFC4360], "Four-octet AS Specific Extended Community"
[RFC5668], and "IPv4 Address Specific Extended Community" [RFC4360]. [RFC5668], and "IPv4 Address Specific Extended Community" [RFC4360].
Route Targets [RFC4360] extended community identify this format in Route Targets [RFC4360] extended community identify this format in
the high-order (Type) octet of the Extended Community. The Import the high-order (Type) octet of the Extended Community. The Import
Route Target extended community will reuses the same mechanism. Route Target extended community reuses the same mechanism.
This document defines the following IRT Extended Communities: This document defines the following IRT Extended Communities:
+------+------+--------------+-------------------------------------+ +------+------+--------------+-------------------------------------+
| | Sub- | Extended | | | | Sub- | Extended | |
| Type | Type | Community | Encoding | | Type | Type | Community | Encoding |
+------+------+--------------+-------------------------------------+ +------+------+--------------+-------------------------------------+
| 0x00 | TBD1 | AS-2byte IRT | 2-octet AS, 4-octet Value | | 0x00 | TBD1 | AS-2byte IRT | 2-octet AS, 4-octet Value |
| 0x01 | TBD2 | IPv4 IRT | 4-octet IPv4 Address, 2-octet Value | | 0x01 | TBD2 | IPv4 IRT | 4-octet IPv4 Address, 2-octet Value |
| 0x02 | TBD3 | AS-4byte IRT | 4-octet AS, 2-octet Value | | 0x02 | TBD3 | AS-4byte IRT | 4-octet AS, 2-octet Value |
skipping to change at page 8, line 27 skipping to change at page 8, line 27
+---------------------------------------------------+ +---------------------------------------------------+
Figure 4. BGP-VPN-INSTANCE NLRI Figure 4. BGP-VPN-INSTANCE NLRI
The Route Type field specifies the encoding of the rest of BGP-VPN- The Route Type field specifies the encoding of the rest of BGP-VPN-
INSTANCE NLRI (Route Type specific BGP-VPN-INSTANCE NLRI). INSTANCE NLRI (Route Type specific BGP-VPN-INSTANCE NLRI).
The Length field indicates the length in octets of the Route Type The Length field indicates the length in octets of the Route Type
specific field of the BGP-VPN-INSTANCE NLRI. specific field of the BGP-VPN-INSTANCE NLRI.
This document defines the following Route Types for BGP-VPN-INSTANCE This document defines the following Route Type for BGP-VPN-INSTANCE
routes: routes:
Type 1: VPN Membership A-D Route Type 1: VPN Membership A-D Route
5.2.1 VPN Membership A-D Route 5.2.1 VPN Membership A-D Route
The VPN Membership A-D Route is utilized for VPN Membership Auto- The VPN Membership A-D Route is utilized for VPN Membership Auto-
Discovery between PEs. Its format is shown in Figure 5. Discovery between PEs. Its format is shown in Figure 5.
+-------------------------------------... +-------------------------------------...
skipping to change at page 11, line 22 skipping to change at page 11, line 22
The following people have substantially contributed to the solution The following people have substantially contributed to the solution
and to the editing of this document:. and to the editing of this document:.
Hui Ni Hui Ni
Huawei Technologies Huawei Technologies
Email: nihui@huawei.com Email: nihui@huawei.com
Acknowledgements Acknowledgements
The authors would like to thank Shuanglong Chen, Eric Wu for their The authors would like to thank Shuanglong Chen and Eric Wu for their
contributions to this work. contributions to this work.
INTERNET-DRAFT BGP Extensions For VPN AD INTERNET-DRAFT BGP Extensions For VPN AD
Normative References Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997, <http://www.rfc- 10.17487/RFC2119, March 1997, <http://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
skipping to change at page 13, line 15 skipping to change at page 13, line 15
INTERNET-DRAFT BGP Extensions For VPN AD INTERNET-DRAFT BGP Extensions For VPN AD
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119
Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May
2017, <https://www.rfc-editor.org/info/rfc8174>. 2017, <https://www.rfc-editor.org/info/rfc8174>.
Informative References Informative References
[I-D.li-mpls-global-label-usecases] Li, Z., Zhao, Q., Yang, T., [I-D.li-mpls-global-label-usecases] Li, Z., Zhao, Q., Yang, T.,
Raszuk, R., and L. Fang, "Usecases of MPLS Global Label", Raszuk, R., and L. Fang, "Usecases of MPLS Global Label",
draft-li-mpls-global- label-usecases-03 (work in progress), draft-li-mpls-global-label-usecases-03 (work in progress),
October 2015. October 2015.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026, DOI Private Network (VPN) Terminology", RFC 4026, DOI
10.17487/RFC4026, March 2005, <https://www.rfc- 10.17487/RFC4026, March 2005, <https://www.rfc-
editor.org/info/rfc4026>. editor.org/info/rfc4026>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE Extensions for PCE-Initiated LSP Setup in a Stateful PCE
skipping to change at page 15, line 9 skipping to change at page 15, line 9
Independent Independent
USA USA
Phone: +1-469-227-5837 Phone: +1-469-227-5837
Email: lucyyong@gmail.com Email: lucyyong@gmail.com
INTERNET-DRAFT BGP Extensions For VPN AD INTERNET-DRAFT BGP Extensions For VPN AD
Copyright, Disclaimer, and Additional IPR Provisions Copyright, Disclaimer, and Additional IPR Provisions
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
 End of changes. 11 change blocks. 
12 lines changed or deleted 14 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/