Ethernet VPN Signalling Extensions for Bit-stream VPWS
Internet-Draft draft-schmutzer-bess-bitstream-vpws-signalling-01
Steven Gringeri
Verizon
USA
steven.gringeri@verizon.com
Jeremy Whittaker
Verizon
USA
jeremy.whittaker@verizon.com
Christian Schmutzer, Ed.
Cisco Systems, Inc.
Austria
cschmutz@cisco.com
Bharath Vasudevan
Cisco Systems, Inc.
Bangalore
India
bhavasud@cisco.com
Patrice Brissette
Cisco Systems, Inc.
Ottawa
Canada
pbrisset@cisco.com
18 April 2024
This document specifies the mechanisms to allow for dynamic signalling of Virtual Private Wire Services (VPWS) carrying bit-stream signals over Packet Switched Networks (PSN).
Introduction and Motivation
Virtual Private Wire Service (VPWS) is a widely deployed technology for providing point-to-point (P2P) services for various layer 2 and also layer 1 technologies. Initially VPWS were define in the Pseudowire Emulation Edge-to-Edge (PWE3) architecture [RFC3985] for Frame Relay, ATM, HDLC, PPP, Ethernet, TDM and SONET/SDH.
How Ethernet VPWS can be signalled using Ethernet VPN has already been specified in [RFC8214]. This document is defining necessary signalling extension for Ethernet VPN to also support the following bit stream VPWS instance types:
- TDM services using SAToP [RFC4553]
- TDM services using CESoP [RFC5086]
- SONET/SDH services using CEP [RFC4842]
- Private line services using PLE [I-D.ietf-pals-ple]
A generic VPWS reference model similar to the one defined in [RFC3985] and [I-D.ietf-pals-ple] is shown in Figure 1. Data received from a CEs is encapsulated by PEs into the respective VPWS established between the attachment circuits of the local and remote PE and transmitted across the Packet Switched Network (PSN) using a PSN tunnel.
VPWS Reference Model

CE1 & CE2 physical                       CE3 & CE4 physical
  interfaces                                interfaces
       |      <------- PSN tunnels ----->      |
       |    +-----------------------------+    |
       |    |                             |    |
+---+  v  +---+                         +---+  v  +---+
|CE1|-----|   |.......... VPWS1 ........|PE2|-----|CE3|
+---+     |   |                         +---+     +---+
          |PE1| packet switched network   |
+----     |   |                         +---+     +---+
|CE2|-----|   |.......... VPWS2 ........|PE3|-----|CE4|
+---+     +---+                         +---+     +---+
          ^ |                             | ^
          | +-----------------------------+ |
          |                                 |
      attachment                       attachment
       circuits                         circuits
          |                                 |
          |<------ emulated services ------>|

Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Terminology
- AIS - Alarm Indication Signal
- AFI - Address Family Identifier
- ATM - Asynchronous Transfer Mode
- BGP - Border Gateway Protocol
- CBR - Constant Bit Rate
- CE - Customer Edge
- CEP - SONET/SDH Circuit Emulation over Packet
- CESoP - Structure-aware TDM Circuit Emulation Service over Packet Switched Network
- DF - Designated Forwarder
- EAD - Ethernet Auto Discovery
- FC - Fibre Channel
- EBM - Equipped Bit Mask
- EVI - EVPN Instance
- EVPN - Ethernet Virtual Private Network
- HDLC - High-level Data Link Control
- LDP - Label Distribution Protocol
- MPLS - Multi Protocol Label Switching
- MTU - Maximum Transmission Unit
- NDF - Non-Designated Forwarder
- NLRI - Network Layer Reachability Information
- OC - Optical Carrier
- ODUk - Optical Data Unit k
- PDH - Plesynchronous Digital Hierarchy
- PE - Provider Edge
- PLE - Private Line Emulation
- PPP - Point-to-Point Protocol
- PSN - Packet Switched Network
- PW - Pseudo Wire
- PWE3 - Pseudowire Emulation Edge-to-Edge
- P2P - Point-to-Point
- RTP - Realtime Transport Protocol
- SAFI - Subsequent Address Family Identifier
- SAToP - Structure Agnostic TDM over Packet
- SDH - Synchronous Digital Hierarchy
- SONET - Synchronous Optical Network
- SRv6 - Segment Routing over IPv6 Dataplane
- STM - Synchronous Transport Module
- STS - Synchronous Transport Signal
- TDM - Time Division Multiplexing
- TLV - Type Length Value
- UNE - Unequipped
- VC - Virtual Circuit
- VPWS - Virtual Private Wire Service
- VT - Virtual Tributary
Solution Requirements
To avoid redefining PW types for [RFC8214] the notion of "PW type" from [RFC8077] is maintained and only a new PW type for [I-D.ietf-pals-ple] has been assigned by IANA.
- TBD1 - Private Line Emulation (PLE) over Packet
The concept of "CEP type" from [RFC5287] to distinguish different connection types that use the same PW type is adopted. In this document it is referred to as "PLE/CEP type". Two new connection types are defined Section 7.3.
To unambiguously identify the rate of an attachment circuit, also the concept of "CEP/TDM bit-rate" from [RFC5287] is adopted and called "PLE/CEP/TDM bit-rate" herein.
The VPWS signalling requirements are as follows:
- Implementations MUST support MPLS as underlay PSN
- The VPWS instance MAY be signalled as SRv6 overlay service per [RFC9252] leveraging on [RFC8986] using the End.DX2 function. In such case, the implementation MUST support SRv6 as underlay PSN.
- The use of control word MUST be signalled, as defined in [RFC4553], [RFC5086], [RFC4842] and [I-D.ietf-pals-ple].
- The PW type MUST be signalled and the PE nodes MUST validate that the PW type is identical on both endpoint.
- For CEP [RFC4842] and PLE [I-D.ietf-pals-ple] the PLE/CEP type MUST be signalled and the PE nodes MUST validate that the PLE/CEP type is identical on both endpoints.
- The PLE/CEP/TDM bit-rate MUST be signalled if the attachment circuit can not be unambiguously identified from the PW type alone and the PE nodes MUST validate that the attachment circuit is identical on both endpoints.
- A non-default payload size MAY be signalled. Both PE nodes MUST validate that the payload size is identical on both endpoints.
- A locally configured connection identifier as defined in Section 7.6 SHOULD be sent to the remote PE node. A locally configured expected identifier MAY be used to identify a misconnection by comparing it with the identifier received from the remote PE node.
- The multi-homed PE scenarios per [RFC7432] and [RFC8214] SHOULD be supported where the load-balancing mode single-active MUST be supported. Port-active load-balancing mode MAY also be supported.
- Multi-homed PE scenarios non-revertive mode MUST and revertive mode SHOULD be supported in compliance to [I-D.ietf-bess-evpn-pref-df].
Service Types
The following sections list all possible service types that are supported by the proposed signalling mechanisms.
Ethernet Service Types
Ethernet Service Types
Service Type | Encapsulation Standard | PW Type | PLE/CEP Type | PLE/CEP/TDM Bit-rate
1000Base-X | [I-D.ietf-pals-ple] | TBD1 | 0x3 | 1,250,000
10GBASE-R | [I-D.ietf-pals-ple] | TBD1 | 0x3 | 10,312,500
25GBASE-R | [I-D.ietf-pals-ple] | TBD1 | 0x3 | 25,791,300
40GBASE-R | [I-D.ietf-pals-ple] | TBD1 | 0x3 | 41,250,000
50GBASE-R | [I-D.ietf-pals-ple] | TBD1 | 0x3 | 51,562,500
100GBASE-R | [I-D.ietf-pals-ple] | TBD1 | 0x3 | 103,125,000
200GBASE-R | [I-D.ietf-pals-ple] | TBD1 | 0x3 | 212,500,000
400GBASE-R | [I-D.ietf-pals-ple] | TBD1 | 0x3 | 425,000,000
Fibre Channel Service Types
Fibre Channel Service Types
Service Type | Encapsulation Standard | PW Type | PLE/CEP Type | PLE/CEP/TDM Bit-rate
1GFC | [I-D.ietf-pals-ple] | TBD1 | 0x3 | 1,062,500
2GFC | [I-D.ietf-pals-ple] | TBD1 | 0x3 | 2,125,000
4GFC | [I-D.ietf-pals-ple] | TBD1 | 0x3 | 4,250,000
8GFC | [I-D.ietf-pals-ple] | TBD1 | 0x3 | 8,500,000
10GFC | [I-D.ietf-pals-ple] | TBD1 | 0x3 | 10,518,750
16GFC | [I-D.ietf-pals-ple] | TBD1 | 0x3 | 14,025,000
32GFC | [I-D.ietf-pals-ple] | TBD1 | 0x3 | 28,050,000
64GFC | [I-D.ietf-pals-ple] | TBD1 | 0x3 | 57,800,000
128GFC | [I-D.ietf-pals-ple] | TBD1 | 0x3 | 112,200,000
OTN Service Types
OTN Service Types
Service Type | Encapsulation Standard | PW Type | PLE/CEP Type | PLE/CEP/TDM Bit-rate
ODU0 | [I-D.ietf-pals-ple] | TBD1 | 0x4 | 1,244,160
ODU1 | [I-D.ietf-pals-ple] | TBD1 | 0x4 | 2,498,775
ODU2 | [I-D.ietf-pals-ple] | TBD1 | 0x4 | 10,037,273
ODU2e | [I-D.ietf-pals-ple] | TBD1 | 0x4 | 10,399,525
ODU3 | [I-D.ietf-pals-ple] | TBD1 | 0x4 | 40,319,218
ODU4 | [I-D.ietf-pals-ple] | TBD1 | 0x4 | 104,794,445
TDM Service Types
TDM Service Types
Service Type | Encapsulation Standard | PW Type | PLE/CEP Type | PLE/CEP/TDM Bit-rate
CESoPSN basic mode | [RFC5086] | 0x0015 | N/A | N
CESoPSN with CAS | [RFC5086] | 0x0017 | N/A | N
E1 | [RFC4553] | 0x0011 | N/A | 32
DS1 | [RFC4553] | 0x0012 | N/A | 24
DS1 octet-aligned | [RFC4553] | 0x0012 | N/A | 25
E3 | [RFC4553] | 0x0013 | N/A | 535
T3 | [RFC4553] | 0x0014 | N/A | 699
SONET/SDH Service Types
Ethernet Service Types
Service Type | Encapsulation Standard | PW Type | PLE/CEP Type | PLE/CEP/TDM Bit-rate
VT1.5/VC-11 | [RFC4842] | 0x0010 | 0x1 | 26
VT2/VC-12 | [RFC4842] | 0x0010 | 0x1 | 35
VT3 | [RFC4842] | 0x0010 | 0x1 | 53
VT6/VC-2 | [RFC4842] | 0x0010 | 0x1 | 107
STS-Nc | [RFC4842] | 0x0010 | 0x0 | 783*N
VC-4-Mc | [RFC4842] | 0x0010 | 0x0 | 7833M
Fract. STS1/VC-3 | [RFC4842] | 0x0010 | 0x2 | 783
Fract. VC-4 | [RFC4842] | 0x0010 | 0x2 | 783*4
Async STS1/VC-3 | [RFC4842] | 0x0010 | 0x2 | 783
OC3/STM1 | [I-D.ietf-pals-ple] | TBD1 | 0x3 | 155,520
OC12/STM4 | [I-D.ietf-pals-ple] | TBD1 | 0x3 | 622,080
OC48/STM16 | [I-D.ietf-pals-ple] | TBD1 | 0x3 | 2,488,320
OC192/STM64 | [I-D.ietf-pals-ple] | TBD1 | 0x3 | 9,953,280
OC768/STM256 | [I-D.ietf-pals-ple] | TBD1 | 0x3 | 39,813,120
Reuse of existing BGP EVPN-VPWS Capabilities
A PLE VPWS instance is identified by a pair of per-EVI ethernet A-D routes advertised by two PE nodes establishing the VPWS in accordance to [RFC8214].
The EVPN layer 2 attribute extended community defined in [RFC8214] MUST be supported and added to the per-EVI ethernet A-D route.
- C bit set to 1 to indicate Control Word MUST be present.
- P and B bits are set by dual-homing PEs as per [RFC8214] and [I-D.ietf-bess-evpn-pref-df]
- L2 MTU MUST be set to zero and ignored by the receiver
BGP Bitstream Attribute
To exchange and validate bit-stream specific attachment circuit parameters during the VPWS setup, a new BGP path attribute called "BGP Bitstream attribute" is defined.
The BGP bitstream attribute is an optional and transitive BGP path attribute with the attribute type codepoint TBD2.
The BGP Bitstream attribute can only be attached to Ethernet Auto-Discovery (A-D) routes (Route type 1) defined in [RFC7432]. The usage for other route types and Address Family Identifier (AFI) / Subsequent Address Family Identifier (SAFI) combinations is not allow unless specified in future specifications.
The format is defined as a set of Type/Length/Value (TLV) triplets, described in the following sections and listed in Table 6. This attribute SHOULD only be included with EVPN Network Layer Reachability Information (NLRI).
BGP Bitstream attribute TLV
TLV Type | Name | Length | Mandatory
1 | PW Type TLV | 3 | Y
2 | PLE/CEP/TDM Bit-rate TLV | 5 | Y
3 | PLE/CEP Options TLV | 3 | Y 1*
4 | TDM Options TLV | 13 | Y 2*
5 | PLE/CEP/TDM Payload Bytes TLV | 3 | N
6 | Endpoint-ID TLV | 0..80 | N
- 1* PLE/CEP only
- 2* TDM only
For a particular PSN it is expected that the network operator will choose a common set of parameters per VPWS type, hence efficient BGP update packing as discussed in Section 12 of [RFC4277] is expected to happen.
PW Type TLV
The PW Type TLV MUST be present in the BGP bitstream attribute to signal what type of VPWS instance has to be established. Valid PW types for the mechanisms described in this document can be found in Section 5.
The PW Type TLV format is shown in Figure 2
PW Type TLV

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |             Length            |    Reserved   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|           PW Type           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type : 1
Length : 6
- The total length in octets of the value portion of the TLV.
Reserved / R :
- For future use. MUST be set to ZERO and ignored by receiver.
PW Type :
- A 15-bit quantity containing a value that represents the type of VPWS. Assigned Values are specified in "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)" [RFC4446].
PLE/CEP/TDM Bit-rate TLV
The PLE/CEP/TDM Bit-rate TLV is MANDATORY but MAY be omitted if the attachment circuit type can be unambiguously derived from the PW Type carried in the PW Type TLV. The PLE/CEP/TDM Bit-rate TLV format is shown in Figure 3.
PLE/CEP/TDM Bit-rate TLV

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |             Length            |    Reserved   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     PLE/CEP/TDM Bit-rate                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type : 2
Length : 8
- The total length in octets of the value portion of the TLV.
Reserved :
- 8-bit field for future use. MUST be set to ZERO and ignored by receiver.
PLE/CEP/TDM Bit-rate :
- A four byte field denoting the data rate of the emulated service. Rules defined in [RFC5287] do apply for signalling TDM VPWS. Rules for CEP VPWS are defined in [RFC4842].
  - For PLE [PLE] the bit rate MUST be set to the data rate in units of 1-kbps of the PLE payload.
  - Guidelines for setting the bit rate for SAToP VPWS and CESoP VPWS can be found in [RFC5287]. And for CEP VPWS in [RFC4842].
PLE/CEP Options TLV
The PLE/CEP Options TLV MUST be present when signalling CEP and PLE VPWS instances. The PLE/CPE Options TLV format is shown in Figure 4.
PLE/CEP Options TLV

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |             Length            |    Reserved   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        PLE/CEP Options        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type : 3
Length : 6
- The total length in octets of the value portion of the TLV.
Reserved :
- 8-bit field for future use. MUST be set to ZERO and ignored by receiver.
PLE/CEP Options :
- A two byte field with the format as shown in Figure 5
PLE/CEP Options

 0                                       1
 0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|AIS|UNE|RTP|EBM|      Reserved [0:6]       |  PLE/CEP  | Async |
|   |   |   |   |                           |    Type   |T3 |E3 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

AIS, UNE, RTP, EBM :
- These bits MUST be set to zero and ignored by the receiver except for CEP VPWS. Guidelines for CEP are defined in [RFC4842]
Reserved :
- 7-bit field for future use. MUST be set to ZERO and ignored by receiver.
CEP/PLE Type :
- Indicates the connection type for CEP and PLE. CEP connection types are defined in [RFC4842]. Two new values for PLE are defined in this document:
  - 0x3 - Basic PLE payload
  - 0x4 - Byte aligned PLE payload
Async :
- These bits MUST be set to zero and ignored by the receiver except for CEP VPWS. Guidelines for CEP are defined in [RFC4842]
TDM options TLV
Whether when signalling TDM VPWS the TDM Options TLV MUST be present or MAY be omitted when signalling TDM VPWS instances is defined in [RFC5287]. The TDM Options TLV format is shown in Figure 6.
TDM Options TLV

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |             Length            |    Reserved   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                         TDM Options                           |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type : 4
Length : 16
- The total length in octets of the value portion of the TLV.
Reserved :
- 8-bit field for future use. MUST be set to ZERO and ignored by receiver.
TDM Options :
- A twelve byte field with the format as defined in {Section 3.8 of RFC5287}
PLE/CEP/TDM Payload Bytes TLV
The PLE/CEP/TDM Payload Bytes TLV MAY be included if a non-default payload size is to be used. If this TLV is omitted then the default payload sizes defined in [RFC4553], [RFC5086], [RFC4842] and [PLE] MUST be assumed. The format of the PLE/CEP/TDM Payload Bytes TLV is shown in Figure 7.
PLE/CEP/TDM Payload Bytes TLV

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |             Length            |    Reserved   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   PLE/CEP/TDM Payload Bytes   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type : 5
Length : 6
- The total length in octets of the value portion of the TLV.
Reserved :
- 8-bit field for future use. MUST be set to ZERO and ignored by receiver.
PLE/CEP/TDM Payload Bytes :
- A two byte field denoting the desired payload size to be used. Rules defined in [RFC5287] do apply for signalling TDM VPWS. Rules for CEP VPWS are defined in [RFC4842].
Endpoint-ID TLV
The Endpoint-ID TLV MAY be included to allow for misconnection detection. The Endpoint-ID TLV format is shown in Figure 8.
Endpoint-ID TLV

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |             Length            |               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
//                Endpoint Identifier (variable)               //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type : 6
Length : 3-83
- The total length in octets of the value portion of the TLV.
Endpoint Identifier :
- Arbitrary string of variable length from 0 to 80 octets used to describe the attachment circuit to the remote PE node.
Control Plane Operations
The deployment model shown in figure 3 of [RFC8214] does equally apply to the operations defined in this document.
VPWS Setup and Teardown
After an attachment circuit has been configured to be part of a VPWS instance and has not declared any local defect, the PE node announces his endpoint using a per-EVI ethernet A-D route to other PEs in the PSN via BGP. The Ethernet Tag ID is set to the VPWS instance identifier and the BGP bitstream attribute is included to carry mandatory and optional bit-stream specific attachment circuit parameters.
Both endpoints receiving the EVPN per-EVI A-D route, validate the end to end connectivity by comparing BGP bitstream attributes. Upon successful validation, the VPWS instance comes up and traffic can flow through the PSN. In the scenario where the validation phase fails, the remote PE reachability information is simply ignored and dismissed as a destination candidate. The VPWS instance validation is performed as follow:
- The mandatory PW type parameter MUST be identical
- The mandatory PLE/CEP/TDM Bit-rate parameter MUST be identical. This MAY be skipped if this parameter was not signalled because the attachment circuit rate can be unambiguously derived from the PW type [RFC5287].
- For CEP and PLE, the mandatory CEP/PLE Type parameter signalled via the CEP/PLE Options TLV MUST be identical
- If the payload size was signalled via the optional PLE/CEP/TDM Payload Bytes TLV it MUST be identical and supported by the PE node. Else the default payload size MUST be assumed.
If any of the previous statements is no true or any of the signal CEP/PLE or TDM options is not supported by the PE node, the VPWS instance must stay down and a appropriate defect MUST be declared.
PLE is structure agnostic for SONET/SDH service types and hence can not validate whether a mix of SONET and SDH attachment circuits are connected (by incident) via VPWS. The detection of such misconfiguration is the responsibility of the operator managing the CE nodes.
In case of multi-homed CEs the mechanisms defined in [RFC8214] apply but are limited to the single-active and port-active scenarios.
Whenever the VPWS instance configuration is removed, the PE node MUST withdraw its associated per-EVI ethernet A-D route.
Misconnection Handling
In circuit switched networks it is a common requirement to have the ability to check if the correct two endpoints got connected via a circuit. To confirm that the established bit-stream VPWS service is connecting the appropriate pair of attachment circuits, a Endpoint-ID string MAY be configured on each attachment circuit and communicated to the peer PE node using the Endpoint-ID TLV defined in Section 7.6.
Each endpoint MAY be configured to compare the Endpoint-ID received from the peer PE node to a locally configured expected Endpoint-ID and raise a fault (defect) when the IDs don't match. When a fault is raised, the R bit in the control word must bet set to 1 (backward defect indication) for the VPWS packets sent to the peer PE node. Each endpoint MAY be configured to only compare and report mismatches, but not to raise a fault.
Failure Scenarios
Single-homed CEs
Whenever a attachment circuit does declare a local fault the following operations MUST happen:
- Operations defined in [RFC4553], [RFC5086], [RFC4842] and [I-D.ietf-pals-ple] MUST happen
- The per-EVI ethernet A-D route MAY be withdrawn
Whenever the CE-bound IWF does enter packet loss state the operations defined in [RFC4553], [RFC5086], [RFC4842] and [I-D.ietf-pals-ple] MUST happen.
Multi-homed CEs
Figure 9 demonstrates a multi-homing scenario. CE1 is connected to PE1 and PE2 where PE1 is the designated forwarder while PE2 is the non designated forwarder.
EVPN-VPWS Multi-homing Redundancy

                    PSN
                 +---------+
    DF  +---+    |         |   +---+   +---+
     +--|PE1|----|---------|---|PE3|---|CE2|
+---+/   +---+    |   VPWS1/|   +---+   +---+
|CE1|             |       / |
+---+\   +---+    |      /  |
     +--|PE2|----|-----+   |
   NDF  +---+    |         |
                 +---------+

In Figure 9 PE1 and PE2 are configured for single-active load-balancing mode. Both PEs are advertising a per-ES ethernet A-D route with the same non-zero Ethernet Segment (ES) value and the single-active bit set. This non-zero ES value is called Ethernet Segment Identifier (ESI).
In this example PE1 is elected as Designated Forwarder (DF) for the shared ESI where as PE2 is the Non-Designated Forwarder (NDF) for that segment. The signalling of primary / backup follows exactly the procedure defined in [RFC8214] where P and B bits of the layer 2 attribute extended community are used to settle proper connectivity.
Upon link failure between CE1 and PE1, PE1 and PE2 follows EVPN Ethernet Segment DF Election procedures described in [RFC8214] and [I-D.ietf-bess-evpn-pref-df] for EVPN-VPWS. PE1 leverage mass-withdraw mechanism to tell PE3 to steer traffic over backup connectivity. The per-EVI ethernet A-D route advertisement remains intact. The main purpose is to keep reachability information available for fast convergence purpose. Therefore, the per-EVI ethernet A-D route MAY be withdrawn only under local fault and MUST be withdraw when the circuit is unconfigured.
Port-active operation happens in the same way as single-active load-balancing mode described before but at the port level instead of being at the sub-interface level.
Mandatory Control Word
Both Section 18 of [RFC7432] and Section 3.1 of [RFC8214] do provide guidance on when the use of control should be signalled.
As the bit-stream VPWS types signalled via the mechanisms described in this document mandate a control word to be present, the use of control word MUST always be signalled independent of the underlying PSN characteristics.
Security Considerations
The same Security Considerations described in [RFC8214] are valid for this document.
IANA Considerations
This document defines a new BGP path attribute known as the "BGP bitstream attribute". IANA is requested to assign the codepoint TBD2 in the "BGP Path Attributes" registry to the BGP bitstream attribute.
This document defines a new PW Type for PLE VPWS. IANA is requested to assign the PW type value TBD1 to PLE in the "MPLS Pseudowire Types" registry.
Acknowledgements
to be added
References
Normative References
[RFC4277]

Experience with the BGP-4 Protocol
D. McPherson
K. Patel
January 2006
RFC 4277
DOI 10.17487/RFC4277
[RFC5287]

Control Protocol Extensions for the Setup of Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks
A. Vainshtein
Y(J). Stein
August 2008
RFC 5287
DOI 10.17487/RFC5287
[RFC8214]

Virtual Private Wire Service Support in Ethernet VPN
S. Boutros
A. Sajassi
S. Salam
J. Drake
J. Rabadan
August 2017
RFC 8214
DOI 10.17487/RFC8214
[RFC4553]

Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)
A. Vainshtein, Ed.
YJ. Stein, Ed.
June 2006
RFC 4553
DOI 10.17487/RFC4553
[RFC5086]

Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)
A. Vainshtein, Ed.
I. Sasson
E. Metz
T. Frost
P. Pate
December 2007
RFC 5086
DOI 10.17487/RFC5086
[RFC4842]

Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)
A. Malis
P. Pate
R. Cohen, Ed.
D. Zelig
April 2007
RFC 4842
DOI 10.17487/RFC4842
[I-D.ietf-pals-ple]

Private Line Emulation over Packet Switched Networks
Steven Gringeri
Verizon
Jeremy Whittaker
Verizon
Nicolai Leymann
Deutsche Telekom
Christian Schmutzer
Cisco Systems, Inc.
Chris Brown
Ciena Corporation
21 October 2023
Internet-Draft draft-ietf-pals-ple-01
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
[RFC9252]

BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)
G. Dawra, Ed.
K. Talaulikar, Ed.
R. Raszuk
B. Decraene
S. Zhuang
J. Rabadan
July 2022
RFC 9252
DOI 10.17487/RFC9252
[RFC8986]

Segment Routing over IPv6 (SRv6) Network Programming
C. Filsfils, Ed.
P. Camarillo, Ed.
J. Leddy
D. Voyer
S. Matsushima
Z. Li
February 2021
RFC 8986
DOI 10.17487/RFC8986
[RFC7432]

BGP MPLS-Based Ethernet VPN
A. Sajassi, Ed.
R. Aggarwal
N. Bitar
A. Isaac
J. Uttaro
J. Drake
W. Henderickx
February 2015
RFC 7432
DOI 10.17487/RFC7432
[I-D.ietf-bess-evpn-pref-df]

Preference-based EVPN DF Election
Jorge Rabadan
Nokia
Senthil Sathappan
Nokia
Wen Lin
Juniper Networks
John Drake
Independent
Ali Sajassi
Cisco Systems
9 October 2023
Internet-Draft draft-ietf-bess-evpn-pref-df-13
Informative References
[RFC3985]

Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture
S. Bryant, Ed.
P. Pate, Ed.
March 2005
RFC 3985
DOI 10.17487/RFC3985
[RFC8077]

Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)
L. Martini, Ed.
G. Heron, Ed.
February 2017
STD 84
RFC 8077
DOI 10.17487/RFC8077
[RFC1925]

The Twelve Networking Truths
R. Callon
April 1996
RFC 1925
DOI 10.17487/RFC1925