draft-ietf-bess-evpn-vpws-00.txt   draft-ietf-bess-evpn-vpws-01.txt 
skipping to change at page 1, line 23 skipping to change at page 1, line 23
Dirk Steinberg Dirk Steinberg
Steinberg Consulting Steinberg Consulting
Thomas Beckhaus Thomas Beckhaus
Deutsche Telecom Deutsche Telecom
J. Rabadan J. Rabadan
Alcatel-Lucent Alcatel-Lucent
Expires: August 3, 2015 January 30, 2015 Expires: December 28, 2015 June 26, 2015
VPWS support in EVPN VPWS support in EVPN
draft-ietf-bess-evpn-vpws-00.txt draft-ietf-bess-evpn-vpws-01.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 single-segment and multi-segment PW signaling, and provides need for single-segment and multi-segment PW signaling, and provides
fast protection using data-plane prefix independent convergence upon fast protection using data-plane prefix independent convergence upon
node or link failure. node or link failure.
skipping to change at page 2, line 35 skipping to change at page 2, line 35
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
2. BGP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 6 2. BGP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 6
3 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1 EVPN Layer 2 attributes extended community . . . . . . . . . 7
4 EVPN Comparison to PW Signaling . . . . . . . . . . . . . . . . 8 3 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5 ESI Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . 8 4 EVPN Comparison to PW Signaling . . . . . . . . . . . . . . . . 9
6 Failure Scenarios . . . . . . . . . . . . . . . . . . . . . . . 9 5 ESI Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1 Single-Homed CEs . . . . . . . . . . . . . . . . . . . . . . 9 6 Failure Scenarios . . . . . . . . . . . . . . . . . . . . . . . 10
6.1 Multi-Homed CEs . . . . . . . . . . . . . . . . . . . . . . 9 6.1 Single-Homed CEs . . . . . . . . . . . . . . . . . . . . . . 11
7 VPWS with multiple sites . . . . . . . . . . . . . . . . . . . . 9 6.1 Multi-Homed CEs . . . . . . . . . . . . . . . . . . . . . . 11
8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10 7 VPWS with multiple sites . . . . . . . . . . . . . . . . . . . . 11
9 Security Considerations . . . . . . . . . . . . . . . . . . . . 10 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
10 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9 Security Considerations . . . . . . . . . . . . . . . . . . . . 11
11 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
11.1 Normative References . . . . . . . . . . . . . . . . . . . 10 11 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.2 Informative References . . . . . . . . . . . . . . . . . . 10 11.1 Normative References . . . . . . . . . . . . . . . . . . . 11
11.2 Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 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 signaling single-segment and EVPN for VPWS eliminates the need for signaling single-segment and
multi-segment PWs for p2p Ethernet services. multi-segment PWs for p2p Ethernet services.
skipping to change at page 4, line 43 skipping to change at page 4, line 43
Both services are supported by using the Ethernet A-D per EVI route Both services are supported by using the Ethernet A-D per EVI route
which contains an Ethernet Segment Identifier, in which the customer which contains an Ethernet Segment Identifier, in which the customer
ES is encoded, and an Ethernet Tag, in which the VPWS service ES is encoded, and an Ethernet Tag, in which the VPWS service
instance identifier is encoded. I.e., for both EPL and EVPL instance identifier is encoded. I.e., for both EPL and EVPL
services, a specific VPWS service instance is identified by a pair of services, a specific VPWS service instance is identified by a pair of
Ethernet A-D per EVI routes which together identify the VPWS service Ethernet A-D per EVI routes which together identify the VPWS service
instance endpoints and the VPWS service instance. In the control instance endpoints and the VPWS service instance. In the control
plane the VPWS service instance is identified using the VPWS service plane the VPWS service instance is identified using the VPWS service
instance identifiers advertised by each PE and in the data plane the instance identifiers advertised by each PE and in the data plane the
MPLS label advertised by one PE is used by the other PE to send MPLS label advertised by one PE is used by the other PE to send
traffic for that VPWS service instance. As with the Ethernet Tag in traffic for that VPWS service instance. As with the Ethernet Tag in
standard EVPN, the VPWS service instance identifier has uniqueness standard EVPN, the VPWS service instance identifier has uniqueness
within an EVPN instance. Unlike standard EVPN where the Ethernet Tag within an EVPN instance.
MUST be carried in the MPLS encapsulated frames, VPWS does not use
the Ethernet Tag value in the data plane. The MPLS label is enough to Unlike EVPN where Ethernet Tag ID in EVPN routes are set to zero for
identify the VPWS service instance and provide egress tag translation Port-based, vlan-based, and vlan-bundle interface mode and it is set
at the disposition PE, if required. The Ethernet Segment identifier to non-zero Ethernet tag ID for vlan-aware bundle mode, in EVPN-VPWS,
encoded in the Ethernet A-D per EVI route is not used to identify the for all the four interface modes, Ethernet tag ID in the Ethernet A-D
service, however it can be used for flow-based load-balancing and route MUST be set to a valid value.
mass withdraw functions.
In terms of route advertisement and MPLS label lookup behavior, EVPN-
VPWS resembles the vlan-aware bundle mode of [RFC 7432] such that
when a PE advertises Ethernet A-D per EVI route, the VPWS service
instance serves as a 24-bit normalized Ethernet tag ID. The MPLS
label in this route represents both the EVI and the VPWS service
instance, so that upon receiving an MPLS encapsulated packet, the
disposition PE can identify the egress AC from the lookup of the MPLS
label alone and perform any required tag translation. For EVPL
service, the Ethernet frames transported over an MPLS/IP network MUST
remain tagged with the originating VID and any VID translation is
performed at the disposition PE. For EPL service, the Ethernet frames
are transported as is and the tags are not altered.
The Ethernet Segment identifier encoded in the Ethernet A-D per EVI
route is not used to identify the service, however it can be used for
flow-based load-balancing and mass withdraw functions.
As with standard EVPN, the Ethernet A-D per ES route is used for fast As with standard EVPN, the Ethernet A-D per ES route is used for fast
convergence upon link or node failure and the Ethernet Segment route convergence upon link or node failure and the Ethernet Segment route
is used for auto-discovery of the PEs attached to a given multi-homed is used for auto-discovery of the PEs attached to a given multi-homed
CE and to synchronize state between them. CE and to synchronize state between them.
1.1 Terminology 1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 6, line 32 skipping to change at page 7, line 4
given PE could have thousands of EVPLs configured. It must be given PE could have thousands of EVPLs configured. It must be
possible to configure multiple EVPL services within the same EVI. possible to configure multiple EVPL services within the same EVI.
7. Local access circuits configured to belong to a given EVPN 7. Local access circuits configured to belong to a given EVPN
instance could also belong to different physical access trunks. instance could also belong to different physical access trunks.
8. EPL-LAN and EVP-LAN are possible on the same system and also ESIs 8. EPL-LAN and EVP-LAN are possible on the same system and also ESIs
can be shared between EVPL and EVP-LANs. can be shared between EVPL and EVP-LANs.
2. BGP Extensions 2. BGP Extensions
This document proposes the use of the Ethernet A-D per EVI route to This document proposes the use of the Ethernet A-D per EVI route to
signal VPWS services. The Ethernet Segment Identifier field is set to signal VPWS services. The Ethernet Segment Identifier field is set to
the customer ES and the Ethernet Tag ID 32-bit field is set to the the customer ES and the Ethernet Tag ID 32-bit field is set to the
24-bit VPWS service instance identifier. For both EPL and EVPL 24-bit VPWS service instance identifier. For both EPL and EVPL
services, for a given VPWS service instance the pair of PEs services, for a given VPWS service instance the pair of PEs
instantiating that VPWS service instance will each advertise an instantiating that VPWS service instance will each advertise an
Ethernet A-D per EVI route with its VPWS service instance identifier Ethernet A-D per EVI route with its VPWS service instance identifier
and will each be configured with the other PE's VPWS service instance and will each be configured with the other PE's VPWS service instance
identifier. When each PE has received the other PE's Ethernet A-D per identifier. When each PE has received the other PE's Ethernet A-D per
EVI route the VPWS service instance is instantiated. It should be EVI route the VPWS service instance is instantiated. It should be
noted that the same VPWS service instance identifier may be noted that the same VPWS service instance identifier may be
configured on both PEs. configured on both PEs.
The Route-Target (RT) extended community with which the Ethernet A-D The Route-Target (RT) extended community with which the Ethernet A-D
per EVI route is tagged identifies the EVPN instance in which the per EVI route is tagged identifies the EVPN instance in which the
VPWS service instance is configured. It is the operator's choice as VPWS service instance is configured. It is the operator's choice as
to how many and which VPWS service instances are configured in a to how many and which VPWS service instances are configured in a
given EVPN instance. However, a given EVPN instance MUST NOT be given EVPN instance. However, a given EVPN instance MUST NOT be
configured with both VPWS service instances and standard EVPN multi- configured with both VPWS service instances and standard EVPN multi-
point services. point services.
2.1 EVPN Layer 2 attributes extended community
This draft proposes a new extended community, defined below, to be
included with Ethernet A-D per EVI route.
+------------------------------------+
| Type(0x06)/Sub-type(TBD)(2 octet) |
+------------------------------------+
| Control Flags (2 octets) |
+------------------------------------+
| L2 MTU (2 octets) |
+------------------------------------+
| Reserved (2 octets) |
+------------------------------------+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |C|E|T|R|P|B| (MBZ = MUST Be Zero)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following bits in the Control Flags are defined; the remaining
bits MUST be set to zero when sending and MUST be ignored when
receiving this community.
Name Meaning
P If set to 1 in multihoming single active scenarios, it
indicates that the advertising PE is the Primary PE.
B If set to 1 in multihoming single active scenarios, it
indicates that the advertising PE is the Backup PE.
T If set to 1, the PE is requesting the ability
to send an EVPN VPWS packet that includes a flow label.
R If set to 1, the PE is able to receive an EVPN
packet with a flow label present.
E If set to 1, the PE is able of sending and receiving
Entropy label.
C If set to 1, a Control word [RFC 4448] MUST be present
when sending EVPN packets to this PE.
The combination of entropy label (E bit set) enabled and control word
(C bit set) required is invalid. However the combination of control
word required (C bit set) and flow label transmit (T bit set) and/or
flow label receive (R bit set) is valid.
For Entropy label handling, the transmitting PE knows whether the
receiving PE can support Entropy label or not. So, if receiving PE
cannot support it, then the transmitting PE MUST not send Entropy
label.
3 Operation 3 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)
| V V V V V V | | V V V V V V |
| +-----+ +-----+ +-----+ +-----+ | | +-----+ +-----+ +-----+ +-----+ |
skipping to change at page 10, line 7 skipping to change at page 11, line 30
7 VPWS with multiple sites 7 VPWS with multiple sites
The VPWS among multiple sites (full mesh of P2P connections - one per The VPWS among multiple sites (full mesh of P2P connections - one per
pair of sites) that can be setup automatically without any explicit pair of sites) that can be setup automatically without any explicit
provisioning of P2P connections among the sites is outside the scope provisioning of P2P connections among the sites is outside the scope
of this document. of this document.
8 Acknowledgements 8 Acknowledgements
The authors would like to acknowledge Wen Lin contributions to this The authors would like to acknowledge Wen Lin and Nitin Singh
document. contributions to this document.
9 Security Considerations 9 Security Considerations
This document does not introduce any additional security constraints. This document does not introduce any additional security constraints.
10 IANA Considerations 10 IANA Considerations
TBD. Definition of 2 new flags in the control flags of the Layer 2
extended community described in [RFC4761] as per section 2.1.
11 References 11 References
11.1 Normative References 11.1 Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2 Informative References 11.2 Informative References
[RFC7209] A. Sajassi, R. Aggarwal et. al., "Requirements for Ethernet [RFC7209] A. Sajassi, R. Aggarwal et. al., "Requirements for Ethernet
VPN". VPN".
[EVPN] A. Sajassi, R. Aggarwal et. al., "BGP MPLS Based Ethernet [RFC7432] A. Sajassi, R. Aggarwal et. al., "BGP MPLS Based Ethernet
VPN", draft-ietf-l2vpn-evpn-11.txt. VPN".
[PBB-EVPN] A. Sajassi et. al., "PBB-EVPN", draft-ietf-l2vpn-pbb-evpn- [PBB-EVPN] A. Sajassi et. al., "PBB-EVPN", draft-ietf-l2vpn-pbb-evpn-
08.txt. 08.txt.
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
(VPLS) Using BGP for Auto-Discovery and Signaling", RFC4761, January
2007.
[draft-ietf-idr-link-bandwidth] P. Mohapatra, R. Fernando, "BGP Link [draft-ietf-idr-link-bandwidth] P. Mohapatra, R. Fernando, "BGP Link
Bandwidth Extended Community", draft-ietf-idr-link-bandwidth-06.txt Bandwidth Extended Community", draft-ietf-idr-link-bandwidth-06.txt
Authors' Addresses Authors' Addresses
Sami Boutros Sami Boutros
Cisco Cisco
Email: sboutros@cisco.com Email: sboutros@cisco.com
Ali Sajassi Ali Sajassi
skipping to change at page 11, line 21 skipping to change at page 13, line 4
Ericsson Ericsson
Email: jeff.tantsura@ericsson.com Email: jeff.tantsura@ericsson.com
Dirk Steinberg Dirk Steinberg
Steinberg Consulting Steinberg Consulting
Email: dws@steinbergnet.net Email: dws@steinbergnet.net
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 Alcatel-Lucent
Email: jorge.rabadan@alcatel-lucent.com Email: jorge.rabadan@alcatel-lucent.com
Ryan Bickhart
Juniper Networks
Email: rbickhart@juniper.net
 End of changes. 16 change blocks. 
35 lines changed or deleted 108 lines changed or added

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