draft-ietf-bess-evpn-vpws-06.txt   draft-ietf-bess-evpn-vpws-07.txt 
skipping to change at page 1, line 19 skipping to change at page 1, line 19
Juniper Networks Juniper Networks
Jeff Tantsura Jeff Tantsura
Individual Individual
Dirk Steinberg Dirk Steinberg
Steinberg Consulting Steinberg Consulting
Thomas Beckhaus Thomas Beckhaus
Deutsche Telecom Deutsche Telecom
J. Rabadan J. Rabadan
Nokia Nokia
Expires: December 9, 2016 June 7, 2016 Expires: January 6, 2017 July 5, 2016
VPWS support in EVPN VPWS support in EVPN
draft-ietf-bess-evpn-vpws-06.txt draft-ietf-bess-evpn-vpws-07.txt
Abstract Abstract
This document describes how EVPN can be used to support Virtual This document describes how EVPN can be used to support Virtual
Private Wire Service (VPWS) in MPLS/IP networks. EVPN enables the Private Wire Service (VPWS) in MPLS/IP networks. EVPN enables the
following characteristics for VPWS: single-active as well as all- following characteristics for VPWS: single-active as well as all-
active multi-homing with flow-based load-balancing, eliminates the active multi-homing with flow-based load-balancing, eliminates the
need for traditional way of PW signaling, and provides fast need for traditional way of PW signaling, and provides fast
protection convergence upon node or link failure. protection convergence upon node or link failure.
skipping to change at page 2, line 45 skipping to change at page 2, line 45
5 EVPN Comparison to PW Signaling . . . . . . . . . . . . . . . . 10 5 EVPN Comparison to PW Signaling . . . . . . . . . . . . . . . . 10
6 Failure Scenarios . . . . . . . . . . . . . . . . . . . . . . . 11 6 Failure Scenarios . . . . . . . . . . . . . . . . . . . . . . . 11
6.1 Single-Homed CEs . . . . . . . . . . . . . . . . . . . . . . 11 6.1 Single-Homed CEs . . . . . . . . . . . . . . . . . . . . . . 11
6.2 Multi-Homed CEs . . . . . . . . . . . . . . . . . . . . . . 11 6.2 Multi-Homed CEs . . . . . . . . . . . . . . . . . . . . . . 11
7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
8 Security Considerations . . . . . . . . . . . . . . . . . . . . 11 8 Security Considerations . . . . . . . . . . . . . . . . . . . . 11
9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1 Normative References . . . . . . . . . . . . . . . . . . . 12 10.1 Normative References . . . . . . . . . . . . . . . . . . . 12
10.2 Informative References . . . . . . . . . . . . . . . . . . 12 10.2 Informative References . . . . . . . . . . . . . . . . . . 12
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1 Introduction 1 Introduction
This document describes how EVPN can be used to support Virtual This document describes how EVPN can be used to support Virtual
Private Wire Service (VPWS) in MPLS/IP networks. The use of EVPN Private Wire Service (VPWS) in MPLS/IP networks. The use of EVPN
mechanisms for VPWS brings the benefits of EVPN to p2p services. mechanisms for VPWS brings the benefits of EVPN to p2p services.
These benefits include single-active redundancy as well as all-active These benefits include single-active redundancy as well as all-active
redundancy with flow-based load-balancing. Furthermore, the use of redundancy with flow-based load-balancing. Furthermore, the use of
EVPN for VPWS eliminates the need for traditional way of PW signaling EVPN for VPWS eliminates the need for traditional way of PW signaling
for p2p Ethernet services, as described in section 4. for p2p Ethernet services, as described in section 4.
[EVPN] has the ability to forward customer traffic to/from a given [RFC7432] has the ability to forward customer traffic to/from a given
customer Attachment Circuit (AC), without any MAC lookup. This customer Attachment Circuit (AC), without any MAC lookup. This
capability is ideal in providing p2p services (aka VPWS services). capability is ideal in providing p2p services (aka VPWS services).
[MEF] defines Ethernet Virtual Private Line (EVPL) service as p2p [MEF] defines Ethernet Virtual Private Line (EVPL) service as p2p
service between a pair of ACs (designated by VLANs) and Ethernet service between a pair of ACs (designated by VLANs) and Ethernet
Private Line (EPL) service, in which all traffic flows are between a Private Line (EPL) service, in which all traffic flows are between a
single pair of ports, that in EVPN terminology would mean a single single pair of ports, that in EVPN terminology would mean a single
pair of ESes. EVPL can be considered as a VPWS with only two ACs. In pair of ESes. EVPL can be considered as a VPWS with only two ACs. In
delivering an EVPL service, the traffic forwarding capability of EVPN delivering an EVPL service, the traffic forwarding capability of EVPN
based on the exchange of a pair of Ethernet AD routes is used; based on the exchange of a pair of Ethernet AD routes is used;
whereas, for more general VPWS, traffic forwarding capability of EVPN whereas, for more general VPWS, traffic forwarding capability of EVPN
skipping to change at page 4, line 6 skipping to change at page 4, line 6
uniqueness within an EVPN instance. uniqueness within an EVPN instance.
Unlike EVPN where Ethernet Tag ID in EVPN routes are set to zero for Unlike EVPN where Ethernet Tag ID in EVPN routes are set to zero for
Port-based, vlan-based, and vlan-bundle interface mode and it is set Port-based, vlan-based, and vlan-bundle interface mode and it is set
to non-zero Ethernet tag ID for vlan-aware bundle mode, in EVPN-VPWS, to non-zero Ethernet tag ID for vlan-aware bundle mode, in EVPN-VPWS,
for all the four interface modes, Ethernet tag ID in the Ethernet A-D for all the four interface modes, Ethernet tag ID in the Ethernet A-D
route MUST be set to a valid value in all the service interface route MUST be set to a valid value in all the service interface
types. types.
In terms of route advertisement and MPLS label lookup behavior, EVPN- In terms of route advertisement and MPLS label lookup behavior, EVPN-
VPWS resembles the vlan-aware bundle mode of [RFC 7432] such that VPWS resembles the vlan-aware bundle mode of [RFC7432] such that when
when a PE advertises per EVI Ethernet A-D route, the VPWS service a PE advertises per EVI Ethernet A-D route, the VPWS service instance
instance serves as a 24-bit normalized Ethernet tag ID. The value of serves as a 24-bit normalized Ethernet tag ID. The value of the MPLS
the MPLS label in this route represents both the EVI and the VPWS label in this route represents both the EVI and the VPWS service
service instance, so that upon receiving an MPLS encapsulated packet, instance, so that upon receiving an MPLS encapsulated packet, the
the disposition PE can identify the egress AC from the lookup of the disposition PE can identify the egress AC from the lookup of the MPLS
MPLS label alone and perform any required tag translation. For EVPL label alone and perform any required tag translation. For EVPL
service, the Ethernet frames transported over an MPLS/IP network service, the Ethernet frames transported over an MPLS/IP network
SHOULD remain tagged with the originating VID and any VID translation SHOULD remain tagged with the originating VID and any VID translation
is performed at the disposition PE. For EPL service, the Ethernet is performed at the disposition PE. For EPL service, the Ethernet
frames are transported as is and the tags are not altered. frames are transported as is and the tags are not altered.
The MPLS label value in the Ethernet A-D route can be set to the VNI The MPLS label value in the Ethernet A-D route can be set to the VNI
for VxLAN encap, and this VNI may have a global scope or local scope for VxLAN encap, and this VNI may have a global scope or local scope
per PE and may also be made equal to the VPWS service instance per PE and may also be made equal to the VPWS service instance
identifier set in the Ethernet A-D route. identifier set in the Ethernet A-D route.
skipping to change at page 8, line 22 skipping to change at page 8, line 22
Name Meaning Name Meaning
P If set to 1 in multihoming single-active scenarios, it P If set to 1 in multihoming single-active scenarios, it
indicates that the advertising PE is the Primary PE. indicates that the advertising PE is the Primary PE.
SHOULD be set to 1 for multihoming all-active scenarios. SHOULD be set to 1 for multihoming all-active scenarios.
B If set to 1 in multihoming single-active scenarios, it B If set to 1 in multihoming single-active scenarios, it
indicates that the advertising PE is the Backup PE. indicates that the advertising PE is the Backup PE.
C If set to 1, a Control word [RFC 4448] MUST be present C If set to 1, a Control word [RFC4448] MUST be present
when sending EVPN packets to this PE. when sending EVPN packets to this PE.
A received L2 MTU=0 means no MTU checking against local MTU is A received L2 MTU=0 means no MTU checking against local MTU is
needed. A received non-zero MTU SHOULD be checked against local MTU needed. A received non-zero MTU SHOULD be checked against local MTU
and if there is a mismatch, the local PE MUST not add the remote PE and if there is a mismatch, the local PE MUST NOT add the remote PE
as the EVPN destination for the corresponding VPWS service instance. as the EVPN destination for the corresponding VPWS service instance.
The usage of the Per ES Ethernet AD route is unchanged from its usage The usage of the Per ES Ethernet AD route is unchanged from its usage
in [RFC7432], i.e. the "Single-Active" bit in the flags of the ESI in [RFC7432], i.e. the "Single-Active" bit in the flags of the ESI
Label extended community will indicate if single-active or all-active Label extended community will indicate if single-active or all-active
redundancy is used for this ES. redundancy is used for this ES.
In a multihoming all-active scenario, there is no DF election, and In a multihoming all-active scenario, there is no DF election, and
all the PEs in the ES that are active and ready to forward traffic all the PEs in the ES that are active and ready to forward traffic
to/from the CE will set the P bit to 1. A remote PE will do per-flow to/from the CE will set the P bit to 1. A remote PE will do per-flow
skipping to change at page 9, line 9 skipping to change at page 9, line 9
the Ethernet Segment. the Ethernet Segment.
In multihoming single-active scenario, during transient situations, a In multihoming single-active scenario, during transient situations, a
remote PE receiving P=1 from more than one PE will select the last remote PE receiving P=1 from more than one PE will select the last
advertising PE as the primary PE when forwarding traffic. A remote PE advertising PE as the primary PE when forwarding traffic. A remote PE
receiving B=1 from more than one PE will select only one backup PE. A receiving B=1 from more than one PE will select only one backup PE. A
remote PE MUST receive P=1 from at least one PE before forwarding remote PE MUST receive P=1 from at least one PE before forwarding
traffic. traffic.
As per [RFC6790], if a network uses entropy labels then the control As per [RFC6790], if a network uses entropy labels then the control
word (C bit set) SHOULD not be used when sending EVPN-encapsulated word (C bit set) SHOULD NOT be used when sending EVPN-encapsulated
packets over a P2P LSP. packets over a P2P LSP.
4 Operation 4 Operation
The following figure shows an example of a P2P service deployed with The following figure shows an example of a P2P service deployed with
EVPN. EVPN.
Ethernet Ethernet Ethernet Ethernet
Native |<--------- EVPN Instance ----------->| Native Native |<--------- EVPN Instance ----------->| Native
Service | | Service Service | | Service
(AC) | |<-PSN1->| |<-PSN2->| | (AC) (AC) | |<-PSN1->| |<-PSN2->| | (AC)
skipping to change at page 11, line 14 skipping to change at page 11, line 14
Finally, EVPN may employ data plane egress link protection mechanisms Finally, EVPN may employ data plane egress link protection mechanisms
not available in VPWS. This can be done by the primary PE (on local not available in VPWS. This can be done by the primary PE (on local
AC down) using the label advertised in the per EVI Ethernet A-D route AC down) using the label advertised in the per EVI Ethernet A-D route
by the backup PE to encapsulate the traffic and direct it to backup by the backup PE to encapsulate the traffic and direct it to backup
PE. PE.
6 Failure Scenarios 6 Failure Scenarios
On a link or port failure between the CE and the PE for both single On a link or port failure between the CE and the PE for both single
and multi-homed CEs, unlike [EVPN] the PE must withdraw all the and multi-homed CEs, unlike [RFC7432] the PE must withdraw all the
associated Ethernet AD routes for the VPWS service instances on the associated Ethernet AD routes for the VPWS service instances on the
failed port or link. failed port or link.
6.1 Single-Homed CEs 6.1 Single-Homed CEs
Unlike [EVPN], EVPN-VPWS uses Ethernet AD route advertisements for Unlike [RFC7432], EVPN-VPWS uses Ethernet AD route advertisements
single-homed Ethernet Segments. Therefore, upon a link/port failure for single-homed Ethernet Segments. Therefore, upon a link/port
of this single-homed Ethernet Segment, the PE MUST withdraw the failure of this single-homed Ethernet Segment, the PE MUST withdraw
associated per EVI Ethernet A-D routes. the associated per EVI Ethernet A-D routes.
6.2 Multi-Homed CEs 6.2 Multi-Homed CEs
For a faster convergence in multi-homed scenarios with either Single- For a faster convergence in multi-homed scenarios with either Single-
Active Redundancy or All-active redundancy, mass withdraw technique Active Redundancy or All-active redundancy, mass withdraw technique
as per [EVPN] baseline is used. A PE previously advertising a per ES as per [RFC7432] baseline is used. A PE previously advertising a per
Ethernet A-D route, can withdraw this route signaling to the remote ES Ethernet A-D route, can withdraw this route signaling to the
PEs to switch all the VPWS service instances associated with this remote PEs to switch all the VPWS service instances associated with
multi-homed ES to the backup PE this multi-homed ES to the backup PE
7 Acknowledgements 7 Acknowledgements
The authors would like to acknowledge Jeffrey Zhang, Wen Lin, Nitin The authors would like to acknowledge Jeffrey Zhang, Wen Lin, Nitin
Singh, Senthil Sathappan and Vinod Prabhu for their feedback and Singh, Senthil Sathappan and Vinod Prabhu for their feedback and
contributions to this document. contributions to this document.
8 Security Considerations 8 Security Considerations
The mechanisms in this document use EVPN control plane as defined in The mechanisms in this document use EVPN control plane as defined in
[RFC7432]. Security considerations described in [RFC7432] are equally [RFC7432]. Security considerations described in [RFC7432] are equally
applicable. applicable.
This document uses MPLS and IP-based tunnel technologies to support This document uses MPLS and IP-based tunnel technologies to support
data plane transport. Security considerations described in [RFC7432] data plane transport. Security considerations described in [RFC7432]
and in [ietf-evpn-overlay] are equally applicable. and in [ietf-evpn-overlay] are equally applicable.
9 IANA Considerations 9 IANA Considerations
IANA has allocated the following EVPN Extended Community sub-type in IANA has allocated the following EVPN Extended Community sub-type:
[RFC7153].
0x04 EVPN Layer 2 attributes [RFCXXXX] SUB-TYPE VALUE NAME Reference 0x04
EVPN Layer 2 attributes [RFCXXXX]
10 References 10 References
10.1 Normative References 10.1 Normative References
[KEYWORDS] 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, March 1997. Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March
1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC7432] A. Sajassi, R. Aggarwal et. al., "BGP MPLS Based Ethernet [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
VPN". 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>.
[RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over MPLS Networks",
RFC 4448, April 2006.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L.
Yong, "The Use of Entropy Labels in MPLS Forwarding", November 2012.
10.2 Informative References 10.2 Informative References
[RFC7209] A. Sajassi, R. Aggarwal et. al., "Requirements for Ethernet [MEF] Metro Ethernet Forum, "Ethernet Services Definitions - Phase
VPN". 2", Technical Specification MEF 6.1, April 2008,
<http://metroethernetforum.org/Assets/Technical_Specifications/PDF/
MEF6-1.pdf>.
[RFC7623] A. Sajassi et. al., "PBB-EVPN", "Provider Backbone Bridging Contributors
Combined with Ethernet VPN (PBB-EVPN)".
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service In addition to the authors listed on the front page, the following
(VPLS) Using BGP for Auto-Discovery and Signaling", RFC4761, January co-authors have also contributed to this document:
2007.
Daniel Voyer Bell Canada
Authors' Addresses Authors' Addresses
Sami Boutros Sami Boutros
VMware, Inc. VMware, Inc.
Email: sboutros@vmware.com Email: sboutros@vmware.com
Ali Sajassi Ali Sajassi
Cisco Cisco
Email: sajassi@cisco.com Email: sajassi@cisco.com
skipping to change at page 13, line 21 skipping to change at page 13, line 32
Patrice Brissette Patrice Brissette
Cisco Cisco
Email: pbrisset@cisco.com Email: pbrisset@cisco.com
Thomas Beckhaus Thomas Beckhaus
Deutsche Telecom Deutsche Telecom
Email:Thomas.Beckhaus@telekom.de Email:Thomas.Beckhaus@telekom.de
Jorge Rabadan Jorge Rabadan
Alcatel-Lucent Nokia
Email: jorge.rabadan@alcatel-lucent.com Email: jorge.rabadan@nokia.com
Ryan Bickhart Ryan Bickhart
Juniper Networks Juniper Networks
Email: rbickhart@juniper.net Email: rbickhart@juniper.net
 End of changes. 19 change blocks. 
39 lines changed or deleted 51 lines changed or added

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