idnits 2.17.1 draft-schmutzer-bess-ple-vpws-signalling-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 278: '... o EVPN-VPWS [RFC8214] as signalling protocol MUST be supported...' RFC 2119 keyword, line 280: '... o LDP [RFC8077] MAY be supported as VPWS signalling protocol...' RFC 2119 keyword, line 282: '... Implementations MUST support MPLS as ...' RFC 2119 keyword, line 284: '...he VPWS instance MAY be signalled as S...' RFC 2119 keyword, line 286: '...he implementation MUST support SRv6 as...' (51 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 3, 2021) is 1089 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 166, but not defined == Missing Reference: 'RFC8174' is mentioned on line 166, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'PLE' ** Downref: Normative reference to an Informational RFC: RFC 5086 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group S. Gringeri 3 Internet-Draft J. Whittaker 4 Intended status: Standards Track Verizon 5 Expires: November 4, 2021 C. Schmutzer, Ed. 6 P. Brissette 7 Cisco Systems, Inc. 8 May 3, 2021 10 Private Line Emulation VPWS Signalling 11 draft-schmutzer-bess-ple-vpws-signalling-02 13 Abstract 15 This document specifies the mechanisms to allow for dynamic 16 signalling of Virtual Private Wire Services (VPWS) carrying bit- 17 stream signals over Packet Switched Networks (PSN). 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 4, 2021. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 55 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 56 2. Solution Requirements . . . . . . . . . . . . . . . . . . . . 7 57 3. Service Types . . . . . . . . . . . . . . . . . . . . . . . . 8 58 3.1. Ethernet Service Types . . . . . . . . . . . . . . . . . 8 59 3.2. Fibre Channel Service Types . . . . . . . . . . . . . . . 8 60 3.3. OTN Service Types . . . . . . . . . . . . . . . . . . . . 9 61 3.4. TDM Service Types . . . . . . . . . . . . . . . . . . . . 9 62 3.5. SONET/SDH Service Types . . . . . . . . . . . . . . . . . 9 63 4. EVPN-VPWS signalling . . . . . . . . . . . . . . . . . . . . 10 64 4.1. Reuse of existing BGP EVPN-VPWS capabilities . . . . . . 10 65 4.2. BGP PLE Attribute . . . . . . . . . . . . . . . . . . . . 10 66 4.2.1. PW Type TLV . . . . . . . . . . . . . . . . . . . . . 11 67 4.2.2. PLE/CEP/TDM Bit-rate TLV . . . . . . . . . . . . . . 12 68 4.2.3. PLE/CEP Options TLV . . . . . . . . . . . . . . . . . 13 69 4.2.4. TDM options TLV . . . . . . . . . . . . . . . . . . . 14 70 4.2.5. PLE/CEP/TDM Payload Bytes TLV . . . . . . . . . . . . 15 71 4.2.6. Endpoint-ID TLV . . . . . . . . . . . . . . . . . . . 16 72 4.3. Control Plane Operations . . . . . . . . . . . . . . . . 16 73 4.3.1. VPWS Setup and Teardown . . . . . . . . . . . . . . . 17 74 4.3.2. Misconnection Handling . . . . . . . . . . . . . . . 18 75 4.3.3. Failure Scenarios . . . . . . . . . . . . . . . . . . 18 76 4.3.3.1. Single-homed CEs . . . . . . . . . . . . . . . . 18 77 4.3.3.2. Multi-homed CEs . . . . . . . . . . . . . . . . . 18 78 5. VPWS signalling using LDP . . . . . . . . . . . . . . . . . . 19 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 84 9.2. Informative References . . . . . . . . . . . . . . . . . 21 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 87 1. Introduction 89 Virtual Private Wire Service (VPWS) is a widely deployed technology 90 for providing point-to-point (P2P) services for various layer 2 and 91 also layer 1 technologies. Initially VPWS were define in the 92 Pseudowire Emulation Edge-to-Edge (PWE3) architecture [RFC3985] for 93 Frame Relay, ATM, HDLC, PPP, Ethernet, TDM and SONET/SDH. 95 This document focuses on bit stream VPWS instance types which already 96 got introduced in [RFC3985]. Possible bit stream VPWS instance types 97 and their encapsulation specification documents are: 99 o TDM services using SAToP [RFC4553] 101 o TDM services using CESoP [RFC5086] 103 o SONET/SDH services using CEP [RFC4842] 105 o High-speed private line services using PLE [PLE] 107 Signalling mechanisms and extensions to [RFC8077] required to 108 dynamically signal TDM bit-stream services ([RFC4553], [RFC5086]) and 109 SONET/SDH bit-stream services ([RFC4842]) are already described in 110 [RFC5287]. 112 The scope of this document is to specify extensions to [RFC8077] 113 required to dynamically signal PLE bit-stream services defined in 114 [PLE] and to specify extensions required to use EVPN-VPWS [RFC8214] 115 as a signalling protocol for all bit-stream services mentioned in 116 this document. 118 A generic VPWS reference model similar to the one defined in 119 [RFC3985] and [PLE] is shown in Figure 1. Data received from a CEs 120 is encapsulated by PEs into the respective VPWS established between 121 the attachment circuits of the local and remote PE and transmitted 122 across the Packet Switched Network (PSN) using a PSN tunnel. 124 CE1 & CE2 physical CE3 & CE4 physical 125 interfaces interfaces 126 | <------- PSN tunnels -----> | 127 | +-----------------------------+ | 128 | | | | 129 +---+ v +---+ +---+ v +---+ 130 |CE1|-----| |.......... VPWS1 ........|PE2|-----|CE3| 131 +---+ | | +---+ +---+ 132 |PE1| packet switched network | 133 +---- | | +---+ +---+ 134 |CE2|-----| |.......... VPWS2 ........|PE3|-----|CE4| 135 +---+ +---+ +---+ +---+ 136 ^ | | ^ 137 | +-----------------------------+ | 138 | | 139 attachment attachment 140 circuits circuits 141 | | 142 |<------ emulated services ------>| 144 Figure 1: VPWS Reference Model 146 In the example shown in Figure 1 there are two CE nodes (CE1 and CE2) 147 connected to the same PE node (PE1). CE3 is connected to PE2 and CE4 148 is connected to PE3. There are two VPWS instances established. 149 VPWS1 between CE1 and CE3 and VPWS2 between CE2 and CE4. For traffic 150 to be carried across the network PSN tunnels between PE1 and PE2 and 151 between PE1 and PE3 are needed. 153 In order for a bit stream VPWS instance to come up, the attachment 154 circuit parameters must be identical on both endpoints. The control 155 plane mechanisms described in this document are leveraged to meet 156 this requirement. Mechanisms for misconnection detection and 157 protection switch coordination are also described. 159 1.1. Requirements Language 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 163 "OPTIONAL" in this document are to be interpreted as described in BCP 164 14 [RFC2119] [RFC8174] when, and only when, they appear in all 165 capitals, as shown here. 167 1.2. Terminology 169 o AIS - Alarm Indication Signal 171 o AFI - Address Family Identifier 173 o ATM - Asynchronous Transfer Mode 175 o BGP - Border Gateway Protocol 177 o CBR - Constant Bit Rate 179 o CE - Customer Edge 181 o CEP - SONET/SDH Circuit Emulation over Packet 183 o CESoP - Structure-aware TDM Circuit Emulation Service over Packet 184 Switched Network 186 o DF - Designated Forwarder 188 o EAD - Ethernet Auto Discovery 190 o FC - Fibre Channel 192 o EBM - Equipped Bit Mask 194 o EVI - EVPN Instance 196 o EVPN - Ethernet Virtual Private Network 198 o HDLC - High-level Data Link Control 200 o LDP - Label Distribution Protocol 202 o MPLS - Multi Protocol Label Switching 204 o MTU - Maximum Transmission Unit 206 o NDF - Non-Designated Forwarder 208 o NLRI - Network Layer Reachability Information 210 o OC - Optical Carrier 212 o ODUk - Optical Data Unit k 214 o PDH - Plesynchronous Digital Hierarchy 215 o PE - Provider Edge 217 o PLE - Private Line Emulation 219 o PPP - Point-to-Point Protocol 221 o PSN - Packet Switched Network 223 o PW - Pseudo Wire 225 o PWE3 - Pseudowire Emulation Edge-to-Edge 227 o P2P - Point-to-Point 229 o RTP - Realtime Transport Protocol 231 o SAFI - Subsequent Address Family Identifier 233 o SAToP - Structure Agnostic TDM over Packet 235 o SDH - Synchronous Digital Hierarchy 237 o SONET - Synchronous Optical Network 239 o SRv6 - Segment Routing over IPv6 Dataplane 241 o STM - Synchronous Transport Module 243 o STS - Synchronous Transport Signal 245 o TDM - Time Division Multiplexing 247 o TLV - Type Length Value 249 o UNE - Unequipped 251 o VC - Virtual Circuit 253 o VPWS - Virtual Private Wire Service 255 o VT - Virtual Tributary 257 o 259 2. Solution Requirements 261 To avoid redefining PW types for [RFC8214] the notion of "PW type" 262 from [RFC8077] is maintained and only a new PW type for [PLE] has 263 been assigned by IANA. 265 o TBD1 - Private Line Emulation (PLE) over Packet 267 The concept of "CEP type" from [RFC5287] to distinguish different 268 connection types that use the same PW type is adopted. In this 269 document it is referred to as "PLE/CEP type". Two new connection 270 types are defined (see Section 4.2.3). 272 To unambiguously identify the rate of an attachment circuit, also the 273 concept of "CEP/TDM bit-rate" from [RFC5287] is adopted and called 274 "PLE bit-rate" herein. 276 The VPWS signalling requirements are as follows: 278 o EVPN-VPWS [RFC8214] as signalling protocol MUST be supported 280 o LDP [RFC8077] MAY be supported as VPWS signalling protocol 282 o Implementations MUST support MPLS as underlay PSN 284 o The VPWS instance MAY be signalled as SRv6 overlay service per 285 [srv6_overlay] leveraging on [srv6_netprog] using the End.DX2 286 function. In such case, the implementation MUST support SRv6 as 287 underlay PSN. 289 o The use of control word MUST be signalled, as defined in 290 [RFC4553], [RFC5086], [RFC4842] and [PLE]. 292 o The PW type MUST be signalled and the PE nodes MUST validate that 293 the PW type is identical on both endpoint. 295 o For CEP [RFC4842] and PLE [PLE] the PLE/CEP type MUST be signalled 296 and the PE nodes MUST validate that the PLE/CEP type is identical 297 on both endpoints. 299 o The PLE/CEP/TDM bit-rate MUST be signalled if the attachment 300 circuit can not be unambiguously identified from the PW type alone 301 and the PE nodes MUST validate that the attachment circuit is 302 identical on both endpoints. 304 o A non-default payload size MAY be signalled. Both PE nodes MUST 305 validate that the payload size is identical on both endpoints. 307 o A locally configured connection identifier as defined in 308 Section 4.2.6 SHOULD be sent to the remote PE node. A locally 309 configured expected identifier MAY be used to identify a 310 misconnection by comparing it with the identifier received from 311 the remote PE node. 313 o When using EVPN-VPWS [RFC8214] as a signalling protocol, multi- 314 homed PE scenarios per [RFC7432] and [RFC8214] SHOULD be supported 315 where the load-balancing mode single-active MUST be supported. 316 Port-active load-balancing mode MAY also be supported. 318 o For EVPN-VPWS [RFC8214] multi-homed PE scenarios non-revertive 319 mode MUST and revertive mode SHOULD be supported in compliance to 320 [pref_df]. 322 3. Service Types 324 The following sections list all possible service types that are 325 supported by the proposed signalling mechanisms. 327 3.1. Ethernet Service Types 329 +------------+-----------------+--------+-----------+---------------+ 330 | Service | Encapsulation | PW | PLE/CEP | PLE/CEP/TDM | 331 | Type | Standard | Type | Type | Bit-rate | 332 +------------+-----------------+--------+-----------+---------------+ 333 | 1000BASE-X | [PLE] | TBD1 | 0x3 | 1,250,000 | 334 | 10GBASE-R | [PLE] | TBD1 | 0x3 | 10,312,500 | 335 | 25GBASE-R | [PLE] | TBD1 | 0x3 | 25,791,300 | 336 | 40GBASE-R | [PLE] | TBD1 | 0x3 | 41,250,000 | 337 | 100GBASE-R | [PLE] | TBD1 | 0x3 | 103,125,000 | 338 +------------+-----------------+--------+-----------+---------------+ 340 3.2. Fibre Channel Service Types 342 +-----------+-----------------+--------+-----------+----------------+ 343 | Service | Encapsulation | PW | PLE/CEP | PLE/CEP/TDM | 344 | Type | Standard | Type | Type | Bit-rate | 345 +-----------+-----------------+--------+-----------+----------------+ 346 | 1GFC | [PLE] | TBD1 | 0x3 | 1,062,500 | 347 | 2GFC | [PLE] | TBD1 | 0x3 | 2,125,000 | 348 | 4GFC | [PLE] | TBD1 | 0x3 | 4,250,000 | 349 | 8GFC | [PLE] | TBD1 | 0x3 | 8,500,000 | 350 | 10GFC | [PLE] | TBD1 | 0x3 | 19,518,750 | 351 | 16GFC | [PLE] | TBD1 | 0x3 | 14,025,000 | 352 | 32GFC | [PLE] | TBD1 | 0x3 | 28,050,000 | 353 | 128GFC | [PLE] | TBD1 | 0x3 | 112,200,000 | 354 +-----------+-----------------+--------+-----------+----------------+ 356 3.3. OTN Service Types 358 +----------+----------------+-------+----------------+--------------+ 359 | Service | Encapsulation | PW | PLE/CEP Type | PLE/CEP/TDM | 360 | Type | Standard | Type | | Bit-rate | 361 +----------+----------------+-------+----------------+--------------+ 362 | ODU0 | [PLE] | TBD1 | 0x4 | 1,244,160 | 363 | ODU1 | [PLE] | TBD1 | 0x4 | 2,498,775 | 364 | ODU2 | [PLE] | TBD1 | 0x4 | 10,037,273 | 365 | ODU2e | [PLE] | TBD1 | 0x4 | 10,399,525 | 366 | ODU3 | [PLE] | TBD1 | 0x4 | 40,319,218 | 367 | ODU4 | [PLE] | TBD1 | 0x4 | 104,794,445 | 368 +----------+----------------+-------+----------------+--------------+ 370 3.4. TDM Service Types 372 +------------------+---------------+--------+---------+-------------+ 373 | Service Type | Encapsulation | PW | PLE/CEP | PLE/CEP/TDM | 374 | | Standard | Type | Type | Bit-rate | 375 +------------------+---------------+--------+---------+-------------+ 376 | CESoPSN basic | [RFC5086] | 0x0015 | N/A | N | 377 | mode | | | | | 378 | CESoPSN with CAS | [RFC5086] | 0x0017 | N/A | N | 379 | E1 | [RFC4553] | 0x0011 | N/A | 32 | 380 | DS1 | [RFC4553] | 0x0012 | N/A | 24 | 381 | DS1 octet- | [RFC4553] | 0x0012 | N/A | 25 | 382 | aligned | | | | | 383 | E3 | [RFC4553] | 0x0013 | N/A | 535 | 384 | T3 | [RFC4553] | 0x0014 | N/A | 699 | 385 +------------------+---------------+--------+---------+-------------+ 387 N is the number of DS0 channels in the attachment circuit 389 3.5. SONET/SDH Service Types 390 +------------------+---------------+--------+---------+-------------+ 391 | Service Type | Encapsulation | PW | PLE/CEP | PLE/CEP/TDM | 392 | | Standard | Type | Type | Bit-rate | 393 +------------------+---------------+--------+---------+-------------+ 394 | VT1.5/VC-11 | [RFC4842] | 0x0010 | 0x1 | 26 | 395 | VT2/VC-12 | [RFC4842] | 0x0010 | 0x1 | 35 | 396 | VT3 | [RFC4842] | 0x0010 | 0x1 | 53 | 397 | VT6/VC-2 | [RFC4842] | 0x0010 | 0x1 | 107 | 398 | STS-Nc | [RFC4842] | 0x0010 | 0x0 | 783*N | 399 | VC-4-Mc | [RFC4842] | 0x0010 | 0x0 | 783*3*M | 400 | Fract. STS1/VC-3 | [RFC4842] | 0x0010 | 0x2 | 783 | 401 | Fract. VC-4 | [RFC4842] | 0x0010 | 0x2 | 783*4 | 402 | Async STS1/VC-3 | [RFC4842] | 0x0010 | 0x2 | 783 | 403 | OC3/STM1 | [PLE] | TBD1 | 0x3 | 155,520 | 404 | OC12/STM4 | [PLE] | TBD1 | 0x3 | 622,080 | 405 | OC48/STM16 | [PLE] | TBD1 | 0x3 | 2,488,320 | 406 | OC192/STM64 | [PLE] | TBD1 | 0x3 | 9,953,280 | 407 | OC768/STM256 | [PLE] | TBD1 | 0x3 | 39,813,120 | 408 +------------------+---------------+--------+---------+-------------+ 410 N=1,3,12,48,192,768 and M=1,4,16,64,256 412 4. EVPN-VPWS signalling 414 4.1. Reuse of existing BGP EVPN-VPWS capabilities 416 A PLE VPWS instance is identified by a pair of per-EVI ethernet A-D 417 routes advertised by two PE nodes establishing the VPWS in accordance 418 to [RFC8214]. 420 The EVPN layer 2 attribute extended community defined in [RFC8214] 421 MUST be supported and added to the per-EVI ethernet A-D route. 423 o C bit set to 1 to indicate Control Word MUST be present. 425 o P and B bits are set by dual-homing PEs as per [RFC8214] and 426 [pref_df] 428 o L2 MTU MUST be set to zero and ignored by the receiver 430 4.2. BGP PLE Attribute 432 To exchange and validate bit-stream specific attachment circuit 433 parameters during the VPWS setup, a new BGP path attribute called 434 "BGP PLE attribute" is defined. 436 The BGP PLE attribute defined in this document can be attached to 437 EVPN VPWS routes [RFC8214]. The usage for other Address Family 438 Identifier (AFI) / Subsequent Address Family Identifier (SAFI) 439 combinations is not defined herein but may be specified in future 440 specifications. 442 The BGP PLE attribute is an optional and transitive BGP path 443 attribute. The attribute type code TBD2 has been assigned by IANA 444 (see section Section 6) 446 The format is defined as a set of Type/Length/Value (TLV) triplets, 447 described in the following sections and listed in Table 1. This 448 attribute SHOULD only be included with EVPN Network Layer 449 Reachability Information (NLRI). 451 +----------+-------------------------------+--------+-----------+ 452 | TLV Type | Name | Length | Mandatory | 453 +----------+-------------------------------+--------+-----------+ 454 | 1 | PW Type TLV | 3 | Y | 455 | 2 | PLE/CEP/TDM Bit-rate TLV | 5 | Y | 456 | 3 | PLE/CEP Options TLV | 3 | Y 1* | 457 | 4 | TDM Options TLV | 13 | Y 2* | 458 | 5 | PLE/CEP/TDM Payload Bytes TLV | 3 | N | 459 | 6 | Endpoint-ID TLV | 0..80 | N | 460 +----------+-------------------------------+--------+-----------+ 462 1* PLE/CEP only, 2* TDM only 464 Table 1: BGP PLE attribute TLVs 466 For a particular PSN it is expected that the network operator will 467 choose a common set of parameters per VPWS type, hence efficient BGP 468 update packing as discussed in section 12 of [RFC4277] is expected to 469 happen. 471 4.2.1. PW Type TLV 473 The PW Type TLV MUST be present in the BGP PLE attribute to signal 474 what type of VPWS instance has to be established. Valid PW types for 475 the mechanisms described in this document can be found in Section 3. 477 The PW Type TLV format is shown in Figure 2. 479 0 1 2 3 480 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 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Type | Length | Reserved | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 |R| PW Type | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 Figure 2: PW type TLV 489 Type : 1 491 Length : 3 493 The total length in octets of the value portion of the TLV. 495 Reserved / R : 497 For future use. MUST be set to ZERO and ignored by receiver. 499 PW Type : 501 A 15-bit quantity containing a value that represents the type of 502 VPWS. Assigned Values are specified in "IANA Allocations for 503 Pseudowire Edge to Edge Emulation (PWE3)" [RFC4446]. 505 4.2.2. PLE/CEP/TDM Bit-rate TLV 507 The PLE/CEP/TDM Bit-rate TLV is MANDATORY but MAY be omitted if the 508 attachment circuit type can be unambiguously derived from the PW Type 509 carried in the PW Type TLV. The PLE/CEP/TDM Bit-rate TLV format is 510 shown in Figure 3. 512 0 1 2 3 513 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 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | Type | Length | Reserved | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | PLE/CEP/TDM Bit-rate | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 Figure 3: PLE/CEP/TDM Bit-rate TLV 522 Type : 2 524 Length : 5 526 The total length in octets of the value portion of the TLV. 528 Reserved : 530 8-bit field for future use. MUST be set to ZERO and ignored by 531 receiver. 533 PLE/CEP/TDM Bit-rate : 535 A four byte field denoting the desired payload size to be used. 536 Rules defined in [RFC5287] do apply for signalling TDM VPWS. 537 Rules for CEP VPWS are defined in [RFC4842]. 539 * For PLE [PLE] the bit rate MUST be set to the data rate in 540 units of 1-kbps of the PLE payload. 542 * Guidelines for setting the bit rate for SAToP VPWS and CESoP 543 VPWS can be found in [RFC5287]. And for CEP VPWS in [RFC4842]. 545 4.2.3. PLE/CEP Options TLV 547 The PLE/CEP Options TLV MUST be present when signalling CEP and PLE 548 VPWS instances. The PLE/CPE Options TLV format is shown in Figure 4. 550 0 1 2 3 551 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 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Type | Length | Reserved | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | PLE/CEP Options | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 Figure 4: PLE/CEP Options TLV 560 Type : 3 562 Length : 3 564 The total length in octets of the value portion of the TLV. 566 Reserved : 568 8-bit field for future use. MUST be set to ZERO and ignored by 569 receiver. 571 PLE/CEP Options : 573 A two byte field with the format as shown in Figure 5 574 0 1 575 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 576 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 577 |AIS|UNE|RTP|EBM| Reserved [0:6] | PLE/CEP | Async | 578 | | | | | | Type |T3 |E3 | 579 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 581 Figure 5: PLE/CEP Options 583 AIS, UNE, RTP, EBM : 585 These bits MUST be set to zero and ignored by the receiver 586 except for CEP VPWS. Guidelines for CEP are defined in 587 [RFC4842] 589 Reserved : 591 7-bit field for future use. MUST be set to ZERO and ignored by 592 receiver. 594 CEP/PLE Type : 596 Indicates the connection type for CEP and PLE. CEP connection 597 types are defined in [RFC4842]. Two new values for PLE are 598 defined in this document: 600 0x3 - Constand Bit Rate (CBR) PLE payload 602 0x4 - Byte aligned PLE payload 604 Async : 606 These bits MUST be set to zero and ignored by the receiver 607 except for CEP VPWS. Guidelines for CEP are defined in 608 [RFC4842] 610 4.2.4. TDM options TLV 612 Whether when signalling TDM VPWS the TDM Options TLV MUST be present 613 or MAY be omitted when signalling TDM VPWS instances is defined in 614 [RFC5287]. The TDM Options TLV format is shown in Figure 6. 616 0 1 2 3 617 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 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Type | Length | Reserved | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | | 622 + + 623 | TDM Options | 624 + + 625 | | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 Figure 6: TDM Options TLV 630 Type : 4 632 Length : 13 634 The total length in octets of the value portion of the TLV. 636 Reserved : 638 8-bit field for future use. MUST be set to ZERO and ignored by 639 receiver. 641 TDM Options : 643 A twelve byte field with the format as defined in section 3.8 of 644 [RFC5287] 646 4.2.5. PLE/CEP/TDM Payload Bytes TLV 648 The PLE/CEP/TDM Payload Bytes TLV MAY be included if a non-default 649 payload size is to be used. If this TLV is omitted then the default 650 payload sizes defined in [RFC4553], [RFC5086], [RFC4842] and [PLE] 651 MUST be assumed. The format of the PLE/CEP/TDM Payload Bytes TLV is 652 shown in Figure 7. 654 0 1 2 3 655 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 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Type | Length | Reserved | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | PLE/CEP/TDM Payload Bytes | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 Figure 7: PLE/CEP/TDM Payload Bytes TLV 664 Type : 5 666 Length : 3 668 The total length in octets of the value portion of the TLV. 670 Reserved : 672 8-bit field for future use. MUST be set to ZERO and ignored by 673 receiver. 675 PLE/CEP/TDM Payload Bytes : 677 A two byte field denoting the desired payload size to be used. 678 Rules defined in [RFC5287] do apply for signalling TDM VPWS. 679 Rules for CEP VPWS are defined in [RFC4842]. 681 4.2.6. Endpoint-ID TLV 683 The Endpoint-ID TLV MAY be included to allow for misconnection 684 detection. The Endpoint-ID TLV format is shown in Figure 8. 686 0 1 2 3 687 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 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Type | Length | | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 691 // Endpoint Identifier (variable) // 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 Figure 8: Endpoint-ID TLV 696 Type : 6 698 Length : 0-80 700 The total length in octets of the value portion of the TLV. 702 Endpoint Identifier : 704 Arbitrary string of variable length from 0 to 80 octets used to 705 describe the attachment circuit to the remote PE node. 707 4.3. Control Plane Operations 709 The deployment model shown in figure 3 of [RFC8214] does equally 710 apply to the operations defined in this document. 712 4.3.1. VPWS Setup and Teardown 714 After an attachment circuit has been configured to be part of a VPWS 715 instance and has not declared any local defect, the PE node announces 716 his endpoint using a per-EVI ethernet A-D route to other PEs in the 717 PSN via BGP. The Ethernet Tag ID is set to the VPWS instance 718 identifier and the BGP PLE attribute is included to carry mandatory 719 and optional bit-stream specific attachment circuit parameters. 721 Both endpoints receiving the EVPN per-EVI A-D route, validate the end 722 to end connectivity by comparing BGP PLE attributes. Upon successful 723 validation, the VPWS instance comes up and traffic can flow through 724 the PSN. In the scenario where the validation phase fails, the 725 remote PE reachability information is simply ignored and dismissed as 726 a destination candidate. The VPWS instance validation is performed 727 as follow: 729 o The mandatory PW type parameter MUST be identical 731 o The mandatory PLE/CEP/TDM Bit-rate parameter MUST be identical. 732 This MAY be skipped if this parameter was not signaled because the 733 attachment circuit rate can be unambiguously derived from the PW 734 type [RFC5287]. 736 o For CEP and PLE, the mandatory CEP/PLE Type parameter signalled 737 via the CEP/PLE Options TLV MUST be identical 739 o If the payload size was signalled via the optional PLE/CEP/TDM 740 Payload Bytes TLV it MUST be identical and supported by the PE 741 node. Else the default payload size MUST be assumed. 743 o If any of the previous statements is no true or any of the signal 744 CEP/PLE or TDM options is not supported by the PE node, the VPWS 745 instance must stay down and a appropriate defect MUST be declared. 747 PLE is structure agnostic for SONET/SDH service types and hence can 748 not validate whether a mix of SONET and SDH attachment circuits are 749 connected (by incident) via VPWS. The detection of such 750 misconfiguration is the responsibility of the operator managing the 751 CE nodes. 753 In case of multi-homed CEs the mechanisms defined in [RFC8214] apply 754 but are limited to the single-active and port-active scenarios. 756 Whenever the VPWS instance configuration is removed, the PE node MUST 757 widthdraw its associated per-EVI ethernet A-D route. 759 4.3.2. Misconnection Handling 761 In circuit switched networks it is a common requirement to have the 762 ability to check if the correct two endpoints got connected via a 763 circuit. To confirm that the established bit-stream VPWS service is 764 connecting the appropriate pair of attachment circuits, a Endpoint-ID 765 string MAY be configured on each attachment circuit and communicated 766 to the peer PE node using the Endpoint-ID TLV defined in 767 Section 4.2.6. 769 Each endpoint MAY be configured to compare the Endpoint-ID received 770 from the peer PE node to a locally configured expected Endpoint-ID 771 and raise a fault (defect) when the IDs don't match. When a fault is 772 raised, the R bit in the control word must bet set to 1 (backward 773 defect indication) for the VPWS packets sent to the peer PE node. 774 Each endpoint MAY be configured to only compare and report 775 mismatches, but not to raise a fault. 777 4.3.3. Failure Scenarios 779 4.3.3.1. Single-homed CEs 781 Whenever a attachment circuit does declare a local fault the 782 following operations MUST happen: 784 o Operations defined in [RFC4553], [RFC5086], [RFC4842] and [PLE] 785 MUST happen 787 o The per-EVI ethernet A-D route MAY be withdrawn 789 Whenever the CE-bound IWF does enter packet loss state the operations 790 defined in [RFC4553], [RFC5086], [RFC4842] and [PLE] MUST happen. 792 4.3.3.2. Multi-homed CEs 794 Figure 9 demonstrates a multi-homing scenario. CE1 is connected to 795 PE1 and PE2 where PE1 is the designated forwarder while PE2 is the 796 non designated forwarder. 798 PSN 799 +---------+ 800 DF +---+ | | +---+ +---+ 801 +--|PE1|----|---------|---|PE3|---|CE2| 802 +---+/ +---+ | VPWS1/| +---+ +---+ 803 |CE1| | / | 804 +---+\ +---+ | / | 805 +--|PE2|----|-----+ | 806 NDF +---+ | | 807 +---------+ 809 Figure 9: EVPN-VPWS multi-homing redundancy 811 In Figure 9 PE1 and PE2 are configured for single-active load- 812 balancing mode. Both PEs are advertising a per-ES ethernet A-D route 813 with the same non-zero Ethernet Segment (ES) value and the single- 814 active bit set. This non-zero ES value is called Ethernet Segment 815 Identifier (ESI). 817 In this example PE1 is elected as Designated Forwarder (DF) for the 818 shared ESI where as PE2 is the Non-Designated Forwarder (NDF) for 819 that segment. The signalling of primary / backup follows exactly the 820 procedure defined in [RFC8214] where P and B bits of the layer 2 821 attribute extended community are used to settle proper connectivity. 823 Upon link failure between CE1 and PE1, PE1 and PE2 follows EVPN 824 Ethernet Segment DF Election procedures described in [RFC8214] and 825 [pref_df] for EVPN-VPWS. PE1 leverage mass-withdraw mechanism to 826 tell PE3 to steer traffic over backup connectivity. The per-EVI 827 ethernet A-D route advertisement remains intact. The main purpose is 828 to keep reachability information available for fast convergence 829 purpose. Therefore, the per-EVI ethernet A-D route MAY be withdrawn 830 only under local fault and MUST be withdraw when the circuit is un- 831 configured. 833 Port-active operation happens in the same way as single-active load- 834 balancing mode described before but at the port level instead of 835 being at the sub-interface level. 837 5. VPWS signalling using LDP 839 This section is already under construction and will be soon be 840 publicly announced 842 6. IANA Considerations 844 This document defines a new BGP path attribute known as the BGP PLE 845 attribute. IANA is requested to assign attribute code type TBD2 to 846 the BGP PLE attribute from the "BGP Path Attributes" registry. 848 This document defines a new PW Type for PLE VPWS. IANA is requested 849 to assign a PW type value TBD1 from the "MPLS Pseudowire Types" 850 registry. 852 7. Security Considerations 854 The same Security Considerations described in [RFC8214] and [RFC5287] 855 are valid for this document. 857 8. Acknowledgements 859 9. References 861 9.1. Normative References 863 [PLE] Schmutzer, C., "draft-cisco-bess-mpls-ple-00", 2020. 865 [pref_df] IETF, "Preference-based EVPN DF Election", 866 . 869 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 870 Emulation (PWE3)", BCP 116, RFC 4446, 871 DOI 10.17487/RFC4446, April 2006, 872 . 874 [RFC4553] Vainshtein, A., Ed. and YJ. Stein, Ed., "Structure- 875 Agnostic Time Division Multiplexing (TDM) over Packet 876 (SAToP)", RFC 4553, DOI 10.17487/RFC4553, June 2006, 877 . 879 [RFC4842] Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig, 880 "Synchronous Optical Network/Synchronous Digital Hierarchy 881 (SONET/SDH) Circuit Emulation over Packet (CEP)", 882 RFC 4842, DOI 10.17487/RFC4842, April 2007, 883 . 885 [RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and 886 P. Pate, "Structure-Aware Time Division Multiplexed (TDM) 887 Circuit Emulation Service over Packet Switched Network 888 (CESoPSN)", RFC 5086, DOI 10.17487/RFC5086, December 2007, 889 . 891 [RFC5287] Vainshtein, A. and Y(J). Stein, "Control Protocol 892 Extensions for the Setup of Time-Division Multiplexing 893 (TDM) Pseudowires in MPLS Networks", RFC 5287, 894 DOI 10.17487/RFC5287, August 2008, 895 . 897 [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and 898 Maintenance Using the Label Distribution Protocol (LDP)", 899 STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, 900 . 902 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 903 Rabadan, "Virtual Private Wire Service Support in Ethernet 904 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 905 . 907 [srv6_netprog] 908 IETF, "SRv6 Network Programming", 909 . 912 [srv6_overlay] 913 IETF, "SRv6 BGP based Overlay services", 914 . 917 9.2. Informative References 919 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 920 Edge-to-Edge (PWE3) Architecture", RFC 3985, 921 DOI 10.17487/RFC3985, March 2005, 922 . 924 [RFC4277] McPherson, D. and K. Patel, "Experience with the BGP-4 925 Protocol", RFC 4277, DOI 10.17487/RFC4277, January 2006, 926 . 928 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 929 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 930 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 931 2015, . 933 Authors' Addresses 935 Steven Gringeri 936 Verizon 938 Email: steven.gringeri@verizon.com 939 Jeremy Whittaker 940 Verizon 942 Email: jeremy.whittaker@verizon.com 944 Christian Schmutzer (editor) 945 Cisco Systems, Inc. 946 Vienna 947 Austria 949 Email: cschmutz@cisco.com 951 Patrice Brissette 952 Cisco Systems, Inc. 953 Ottawa, ON 954 Canada 956 Email: pbrisset@cisco.com