idnits 2.17.1 draft-schmutzer-bess-ple-vpws-signalling-00.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 281: '... o EVPN-VPWS [RFC8214] as signalling protocol MUST be supported...' RFC 2119 keyword, line 283: '... o LDP [RFC8077] MAY be supported as VPWS signalling protocol...' RFC 2119 keyword, line 285: '... Implementations MUST support MPLS as ...' RFC 2119 keyword, line 287: '...he VPWS instance MAY be signalled as S...' RFC 2119 keyword, line 289: '...he implementation MUST support SRv6 as...' (48 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2020) is 1384 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 161, but not defined == Missing Reference: 'RFC8174' is mentioned on line 161, 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: January 13, 2021 C. Schmutzer, Ed. 6 P. Brissette 7 Cisco Systems, Inc. 8 July 12, 2020 10 Private Line Emulation VPWS Signalling 11 draft-schmutzer-bess-ple-vpws-signalling-00 13 Abstract 15 This document specifies the mechanisms to signal Virtual Private Wire 16 Services (VPWS) carrying bit-stream signals over Packet Switched 17 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 January 13, 2021. 36 Copyright Notice 38 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . 10 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. Failure Scenarios . . . . . . . . . . . . . . . . . . 18 75 4.3.2.1. Single-homed CEs . . . . . . . . . . . . . . . . 18 76 4.3.2.2. Multi-homed CEs . . . . . . . . . . . . . . . . . 18 77 5. VPWS signalling using LDP . . . . . . . . . . . . . . . . . . 19 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 83 9.2. Informative References . . . . . . . . . . . . . . . . . 21 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 86 1. Introduction 88 Virtual Private Wire Service (VPWS) is a widely deployed technology 89 for providing point-to-point (P2P) services for various layer 2 and 90 also layer 1 technologies. Initially VPWS were define in the 91 Pseudowire Emulation Edge-to-Edge (PWE3) architecture [RFC3985] for 92 Frame Relay, ATM, HDLC, PPP, Ethernet, TDM and SONET/SDH. 94 Later on the adoption of BGP [RFC4271] as a protocol for delivering 95 ethernet layer 2 services led to Ethernet VPNs [RFC7432] and EVPN- 96 VPWS [RFC8214] respectively. 98 This document focuses on bit stream VPWS instance types which already 99 got introduced in [RFC3985] and describes mechanisms that can be used 100 to discover and establish such VPWS instances by a means of a dynamic 101 protocol rather than manual configuration on both endpoints. 103 Possible bit stream VPWS instance types are: 105 o TDM services using SAToP [RFC4553] 107 o TDM services using CESoP [RFC5086] 109 o SONET/SDH services using CEP [RFC4842] 111 o High-speed private line services using PLE [PLE] 113 A generic VPWS reference model similar to the one defined in 114 [RFC3985] and [PLE] is shown in Figure 1. Data received from a CEs 115 is encapsulated by PEs into the respective VPWS established between 116 the attachment circuits of the local and remote PE and transmitted 117 across the Packet Switched Network (PSN) using a PSN tunnel. 119 CE1 & CE2 physical CE3 & CE4 physical 120 interfaces interfaces 121 | <------- PSN tunnels -----> | 122 | +-----------------------------+ | 123 | | | | 124 +---+ v +---+ +---+ v +---+ 125 |CE1|-----| |.......... VPWS1 ........|PE2|-----|CE3| 126 +---+ | | +---+ +---+ 127 |PE1| packet switched network | 128 +---- | | +---+ +---+ 129 |CE2|-----| |.......... VPWS2 ........|PE3|-----|CE4| 130 +---+ +---+ +---+ +---+ 131 ^ | | ^ 132 | +-----------------------------+ | 133 | | 134 attachment attachment 135 circuits circuits 136 | | 137 |<------ emulated services ------>| 139 Figure 1: VPWS Reference Model 141 In the example shown in Figure 1 there are two CE nodes (CE1 and CE2) 142 connected to the same PE node (PE1). CE3 is connected to PE2 and CE4 143 is connected to PE3. There are two VPWS instances established. 144 VPWS1 between CE1 and CE3 and VPWS2 between CE2 and CE4. For traffic 145 to be carried across the network PSN tunnels between PE1 and PE2 and 146 between PE1 and PE3 are needed. 148 In order for a bit stream VPWS instance to come up, the attachment 149 circuit parameters must be identical on both endpoints. The control 150 plane mechanisms described in this document are leveraged to meet 151 this requirement. Mechanisms for misconnection detection and 152 protection switch coordination are also described. 154 1.1. Requirements Language 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 158 "OPTIONAL" in this document are to be interpreted as described in BCP 159 14 [RFC2119] [RFC8174] when, and only when, they appear in all 160 capitals, as shown here. 162 1.2. Terminology 164 o AIS - Alarm Indication Signal 166 o AFI - Address Family Identifier 168 o ATM - Asynchronous Transfer Mode 170 o BGP - Border Gateway Protocol 172 o CBR - Constant Bit Rate 174 o CE - Customer Edge 176 o CEP - SONET/SDH Circuit Emulation over Packet 178 o CESoP - Structure-aware TDM Circuit Emulation Service over Packet 179 Switched Network 181 o DF - Designated Forwarder 183 o EAD - Ethernet Auto Discovery 185 o FC - Fibre Channel 187 o EBM - Equipped Bit Mask 189 o EVI - EVPN Instance 191 o EVPN - Ethernet Virtual Private Network 193 o HDLC - High-level Data Link Control 195 o LDP - Label Distribution Protocol 197 o MPLS - Multi Protocol Label Switching 199 o MTU - Maximum Transmission Unit 201 o NDF - Non-Designated Forwarder 203 o NLRI - Network Layer Reachability Information 205 o OC - Optical Carrier 207 o ODUk - Optical Data Unit k 209 o PDH - Plesynchronous Digital Hierarchy 210 o PE - Provider Edge 212 o PLE - Private Line Emulation 214 o PPP - Point-to-Point Protocol 216 o PSN - Packet Switched Network 218 o PW - Pseudo Wire 220 o PWE3 - Pseudowire Emulation Edge-to-Edge 222 o P2P - Point-to-Point 224 o RTP - Realtime Transport Protocol 226 o SAFI - Subsequent Address Family Identifier 228 o SAToP - Structure Agnostic TDM over Packet 230 o SDH - Synchronous Digital Hierarchy 232 o SONET - Synchronous Optical Network 234 o SRv6 - Segment Routing over IPv6 Dataplane 236 o STM - Synchronous Transport Module 238 o STS - Synchronous Transport Signal 240 o TDM - Time Division Multiplexing 242 o TLV - Type Length Value 244 o UNE - Unequipped 246 o VC - Virtual Circuit 248 o VPWS - Virtual Private Wire Service 250 o VT - Virtual Tributary 252 o 254 2. Solution Requirements 256 The scope of this document is to specify signalling mechanisms for 257 PLE bit-stream services as defined in [PLE]. 259 For legacy bit-stream services that have been defined for TDM 260 [RFC4553] and [RFC5086] as well as SONET/SDH [RFC4842], additional 261 signalling mechanisms are described to complement the mechanisms 262 defined in [RFC5287]. 264 To avoid redefining PW types for [RFC8214] the notion of "PW type" 265 from [RFC8077] is maintained and only a new PW type for [PLE] has 266 been assigned by IANA. 268 o TBD1 - Private Line Emulation (PLE) over Packet 270 The concept of "CEP type" from [RFC5287] to distinguish different 271 connection types that use the same PW type is adopted. In this 272 document it is referred to as "PLE/CEP type". Two new connection 273 types are defined (see Section 4.2.3). 275 To unambiguously identify the rate of an attachment circuit, also the 276 concept of "CEP/TDM bit-rate" from [RFC5287] is adopted and called 277 "PLE bit-rate" herein. 279 The VPWS signalling requirements are as follows: 281 o EVPN-VPWS [RFC8214] as signalling protocol MUST be supported 283 o LDP [RFC8077] MAY be supported as VPWS signalling protocol 285 o Implementations MUST support MPLS as underlay PSN 287 o The VPWS instance MAY be signalled as SRv6 overlay service per 288 [srv6_overlay] leveraging on [srv6_netprog] using the End.DX2 289 function. In such case, the implementation MUST support SRv6 as 290 underlay PSN. 292 o The use of control word as defined in [RFC4553], [RFC5086], 293 [RFC4842] and [PLE] MUST be signalled. 295 o The PW type MUST be signalled and the PE nodes MUST validate that 296 the PW type is identical on both endpoint. 298 o For CEP [RFC4842] and PLE [PLE] the PLE/CEP type MUST be signalled 299 and the PE nodes MUST validate that the PLE/CEP type is identical 300 on both endpoints. 302 o The PLE/CEP/TDM bit-rate MUST be signalled if the attachment 303 circuit rate can not be unambiguously identified from the PW type 304 alone and the PE nodes MUST validate that the attachment circuit 305 rate is identical on both endpoints. 307 o A non-default payload size MAY be signalled. Both PE nodes MUST 308 validate that the payload size is identical on both endpoints. 310 o A locally configured connection identifier as defined in 311 Section 4.2.6 SHOULD be exchanged and MAY be used to identify a 312 misconnection by comparing the locally configured identifier with 313 the received identifier from the remote PE node. 315 o Multi-homed PE scenarios per [RFC7432] and [RFC8214] SHOULD be 316 supported where the load-balancing mode single-active MUST be 317 supported. Port-active load-balancing mode MAY also be supported. 319 o For multi-homed PE scenarios non-revertive mode MUST and revertive 320 mode SHOULD be supported in compliance to [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 341 +-----------+-----------------+--------+-----------+----------------+ 342 | Service | Encapsulation | PW | PLE/CEP | PLE/CEP/TDM | 343 | Type | Standard | Type | Type | Bit-rate | 344 +-----------+-----------------+--------+-----------+----------------+ 345 | 1GFC | [PLE] | TBD1 | 0x3 | 1,062,500 | 346 | 2GFC | [PLE] | TBD1 | 0x3 | 2,125,000 | 347 | 4GFC | [PLE] | TBD1 | 0x3 | 4,250,000 | 348 | 8GFC | [PLE] | TBD1 | 0x3 | 8,500,000 | 349 | 10GFC | [PLE] | TBD1 | 0x3 | 19,518,750 | 350 | 16GFC | [PLE] | TBD1 | 0x3 | 14,025,000 | 351 | 32GFC | [PLE] | TBD1 | 0x3 | 28,050,000 | 352 | 128GFC | [PLE] | TBD1 | 0x3 | 112,200,000 | 353 +-----------+-----------------+--------+-----------+----------------+ 355 3.3. OTN Service Types 357 +----------+----------------+-------+----------------+--------------+ 358 | Service | Encapsulation | PW | PLE/CEP Type | PLE/CEP/TDM | 359 | Type | Standard | Type | | Bit-rate | 360 +----------+----------------+-------+----------------+--------------+ 361 | ODU0 | [PLE] | TBD1 | 0x4 | 1,244,160 | 362 | ODU1 | [PLE] | TBD1 | 0x4 | 2,498,775 | 363 | ODU2 | [PLE] | TBD1 | 0x4 | 10,037,273 | 364 | ODU2e | [PLE] | TBD1 | 0x4 | 10,399,525 | 365 | ODU3 | [PLE] | TBD1 | 0x4 | 40,319,218 | 366 | ODU4 | [PLE] | TBD1 | 0x4 | 104,794,445 | 367 +----------+----------------+-------+----------------+--------------+ 369 3.4. TDM Service Types 371 +------------------+---------------+--------+---------+-------------+ 372 | Service Type | Encapsulation | PW | PLE/CEP | PLE/CEP/TDM | 373 | | Standard | Type | Type | Bit-rate | 374 +------------------+---------------+--------+---------+-------------+ 375 | CESoPSN basic | [RFC5086] | 0x0015 | N/A | N | 376 | mode | | | | | 377 | CESoPSN with CAS | [RFC5086] | 0x0017 | N/A | N | 378 | E1 | [RFC4553] | 0x0011 | N/A | 32 | 379 | DS1 | [RFC4553] | 0x0012 | N/A | 24 | 380 | DS1 octet- | [RFC4553] | 0x0012 | N/A | 25 | 381 | aligned | | | | | 382 | E3 | [RFC4553] | 0x0013 | N/A | 535 | 383 | T3 | [RFC4553] | 0x0014 | N/A | 699 | 384 +------------------+---------------+--------+---------+-------------+ 386 N is the number of DS0 channels in the attachment circuit 388 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 - ODUk frame 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 totally 726 dismiss as a destination candidate. The VPWS instance validation is 727 performed 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. Failure Scenarios 761 4.3.2.1. Single-homed CEs 763 Whenever a attachment circuit does declare a local fault the 764 following operations MUST happen: 766 o Operations defined in [RFC4553], [RFC5086], [RFC4842] and [PLE] 767 MUST happen. 769 o The per-EVI ethernet A-D route MAY be withdrawn 771 Whenever the CE-bound IWF does enter packet loss state the operations 772 defined in [RFC4553], [RFC5086], [RFC4842] and [PLE] MUST happen. 774 4.3.2.2. Multi-homed CEs 776 Figure 9 demonstrates a multi-homing scenario. CE1 is connected to 777 PE1 and PE2 where PE1 is the designated forwarder while PE2 is the 778 non designated forwarder. 780 PSN 781 +---------+ 782 DF +---+ | | +---+ +---+ 783 +--|PE1|----|---------|---|PE3|---|CE2| 784 +---+/ +---+ | VPWS1/| +---+ +---+ 785 |CE1| | / | 786 +---+\ +---+ | / | 787 +--|PE2|----|-----+ | 788 NDF +---+ | | 789 +---------+ 791 Figure 9: EVPN-VPWS multi-homing redundancy 793 In Figure 9 PE1 and PE2 are configured for single-active load- 794 balancing mode. Both PEs are advertising a per-ES ethernet A-D route 795 with the same non-zero Ethernet Segment (ES) value and the single- 796 active bit set. This non-zero ES value is called Ethernet Segment 797 Identifier (ESI). 799 In this example PE1 is elected as Designated Forwarder (DF) for the 800 shared ESI where as PE2 is the Non-Designated Forwarder (NDF) for 801 that segment. The signalling of primary / backup follows exactly the 802 procedure defined in [RFC8214] where P and B bits of the layer 2 803 attribute extended community are used to settle proper connectivity. 805 Upon link failure between CE1 and PE1, PE1 and PE2 follows EVPN 806 Ethernet Segment DF Election procedures described in [RFC8214] and 807 [pref_df] for EVPN-VPWS. PE1 leverage mass-withdraw mechanism to 808 tell PE3 to steer traffic over backup connectivity. The per-EVI 809 ethernet A-D route advertisement remains intact. The main purpose is 810 to keep reachability information available for fast convergence 811 purpose. Therefore, the per-EVI ethernet A-D route MAY be withdrawn 812 only under local fault and MUST be withdraw when the circuit is un- 813 configured. 815 Port-active operation happens in the same way as single-active load- 816 balancing mode described before but at the port level instead of 817 being at the sub-interface level. 819 5. VPWS signalling using LDP 821 This section is already under construction and will be soon be 822 publicly announced 824 6. IANA Considerations 826 This document defines a new BGP path attribute known as the BGP PLE 827 attribute. IANA is requested to assign attribute code type TBD2 to 828 the BGP PLE attribute from the "BGP Path Attributes" registry. 830 This document defines a new PW Type for PLE VPWS. IANA is requested 831 to assign a PW type value TBD1 from the "MPLS Pseudowire Types" 832 registry. 834 7. Security Considerations 836 The same Security Considerations described in [RFC8214] and [RFC5287] 837 are valid for this document. 839 8. Acknowledgements 841 9. References 843 9.1. Normative References 845 [PLE] Schmutzer, C., "draft-cisco-bess-mpls-ple-00", 2020. 847 [pref_df] IETF, "Preference-based EVPN DF Election", 848 . 851 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 852 Emulation (PWE3)", BCP 116, RFC 4446, 853 DOI 10.17487/RFC4446, April 2006, 854 . 856 [RFC4553] Vainshtein, A., Ed. and YJ. Stein, Ed., "Structure- 857 Agnostic Time Division Multiplexing (TDM) over Packet 858 (SAToP)", RFC 4553, DOI 10.17487/RFC4553, June 2006, 859 . 861 [RFC4842] Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig, 862 "Synchronous Optical Network/Synchronous Digital Hierarchy 863 (SONET/SDH) Circuit Emulation over Packet (CEP)", 864 RFC 4842, DOI 10.17487/RFC4842, April 2007, 865 . 867 [RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and 868 P. Pate, "Structure-Aware Time Division Multiplexed (TDM) 869 Circuit Emulation Service over Packet Switched Network 870 (CESoPSN)", RFC 5086, DOI 10.17487/RFC5086, December 2007, 871 . 873 [RFC5287] Vainshtein, A. and Y(J). Stein, "Control Protocol 874 Extensions for the Setup of Time-Division Multiplexing 875 (TDM) Pseudowires in MPLS Networks", RFC 5287, 876 DOI 10.17487/RFC5287, August 2008, 877 . 879 [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and 880 Maintenance Using the Label Distribution Protocol (LDP)", 881 STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, 882 . 884 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 885 Rabadan, "Virtual Private Wire Service Support in Ethernet 886 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 887 . 889 [srv6_netprog] 890 IETF, "SRv6 Network Programming", 891 . 894 [srv6_overlay] 895 IETF, "SRv6 BGP based Overlay services", 896 . 899 9.2. Informative References 901 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 902 Edge-to-Edge (PWE3) Architecture", RFC 3985, 903 DOI 10.17487/RFC3985, March 2005, 904 . 906 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 907 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 908 DOI 10.17487/RFC4271, January 2006, 909 . 911 [RFC4277] McPherson, D. and K. Patel, "Experience with the BGP-4 912 Protocol", RFC 4277, DOI 10.17487/RFC4277, January 2006, 913 . 915 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 916 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 917 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 918 2015, . 920 Authors' Addresses 922 Steven Gringeri 923 Verizon 925 Email: steven.gringeri@verizon.com 927 Jeremy Whittaker 928 Verizon 930 Email: jeremy.whittaker@verizon.com 932 Christian Schmutzer (editor) 933 Cisco Systems, Inc. 934 Vienna 935 Austria 937 Email: cschmutz@cisco.com 938 Patrice Brissette 939 Cisco Systems, Inc. 940 Ottawa, ON 941 Canada 943 Email: pbrisset@cisco.com