idnits 2.17.00 (12 Aug 2021) /tmp/idnits26452/draft-busi-pals-pw-cw-stitching-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 abstract seems to contain references ([RFC4448], [RFC6073], [RFC4385], [I-DETH-CW]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2, 2018) is 1419 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: 'RFC 6073' is mentioned on line 598, but not defined == Missing Reference: 'RFC 4385' is mentioned on line 56, but not defined == Missing Reference: 'RFC 4448' is mentioned on line 95, but not defined == Missing Reference: 'RFC 6718' is mentioned on line 147, but not defined == Missing Reference: 'RFC 7771' is mentioned on line 147, but not defined == Missing Reference: 'RFC 4447' is mentioned on line 303, but not defined ** Obsolete undefined reference: RFC 4447 (Obsoleted by RFC 8077) == Missing Reference: 'RFC 5085' is mentioned on line 484, but not defined == Unused Reference: 'RFC4447' is defined on line 643, but no explicit reference was found in the text == Unused Reference: 'RFC5085' is defined on line 650, but no explicit reference was found in the text == Unused Reference: 'RFC6073' is defined on line 654, but no explicit reference was found in the text == Unused Reference: 'RFC6718' is defined on line 669, but no explicit reference was found in the text == Unused Reference: 'RFC7771' is defined on line 672, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: draft-ietf-pals-ethernet-cw has been published as RFC 8469 Summary: 3 errors (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PALS Working Group Italo Busi 2 Internet Draft Stewart Bryant 3 Intended status: Standard Track Andrew G. Malis 4 Expires: January 2019 Jie Dong 5 Huawei 7 July 2, 2018 9 Pseudowire (PW) Control Word (CW) Stitching 10 draft-busi-pals-pw-cw-stitching-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on January 2, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. Code Components extracted from this 46 document must include Simplified BSD License text as described in 47 Section 4.e of the Trust Legal Provisions and are provided without 48 warranty as described in the Simplified BSD License. 50 Abstract 52 This document defines the behavior of a new type of Multi-Segment 53 Pseudowire (MS-PW) Switching PE (S-PE) which enhances the S-PE 54 functions defined in [RFC 6073], with the capability to switch an 55 Ethernet pseudowire (PW) segment that uses the PW Control Word (CW) 56 [RFC 4385] with an Ethernet PW segment that does not use the CW. 58 This new type of S-PE can be deployed in the network one hop away, 59 at the MPLS layer, from a Terminating PE (T-PE) which does not 60 support CW for Ethernet PW encapsulation [RFC 4448]. In this way, 61 all the Ethernet PW packets sent though the MPLS network will have 62 the CW and be protected against incorrect equal-cost-multi-path 63 (ECMP) behavior as described in [I-D ETH-CW]. 65 Table of Contents 67 1. Introduction...................................................2 68 1.1. Assumptions...............................................4 69 2. Terminology....................................................5 70 2.1. Conventions Used in This Document.........................5 71 3. Control Word Stitching procedures..............................6 72 3.1. CW Stitching Signaling....................................6 73 4. VCCV Stitching Procedures......................................8 74 4.1. VCCV Stitching for CC Type 3..............................9 75 4.2. VCCV Stitching for CC Type 4.............................10 76 4.3. VCCV Stitching Signaling.................................12 77 5. Other Deployment Scenarios....................................13 78 6. Security Considerations.......................................15 79 7. IANA Considerations...........................................15 80 8. References....................................................15 81 8.1. Normative References.....................................15 82 8.2. Informative References...................................16 83 9. Acknowledgments...............................................16 85 1. Introduction 87 In order to protect Ethernet pseudowire (PW) packets against 88 incorrect equal-cost-multi-path (ECMP) behavior, which may cause 89 out-of-order delivery of the payload Ethernet frames, the use of PW 90 control word (CW) has been recommended in [I-D ETH-CW]. 92 However, service providers may have deployments where the Provider 93 Edge (PE) device is an old piece of equipment which does not support 94 the CW for Ethernet PW encapsulation. In this case, the CW shall not 95 be used as defined in [RFC 4448]. 97 There are situations where replacing this PE with a new piece of 98 equipment which supports CW for Ethernet PW is not acceptable 99 because of economical or operational (e.g., service disruption time) 100 reasons. 102 It may be beneficial to give operators an option to deploy (or re- 103 use) another piece of equipment, located one hop away at the MPLS 104 layer from this PE (typically physically co-located), which can add 105 the CW to the Ethernet PW packets received from this PE, before 106 sending them though an MPLS network. 108 This node should behave as a Switching PE (S-PE) as defined in [RFC 109 6073] and also be capable of switching an Ethernet pseudowire (PW) 110 segment that uses the control word (CW) with an Ethernet PW segment 111 that does not use the CW. 113 The reference network is shown in Figure 1 below. 115 Original SS-PW 116 (w/o CW) 117 | 118 +-------+ /--------|----------------\ +-------+1 119 | | / V \ | | 120 | T-PE1 +ooooooooooooooooooooooooooooooooooooooooo+ T-PE2 | 121 | | | +ccccccccccccc+ | 122 +---+---+ | c | +-------+ 123 n | c | 124 n<-----+ | MPLS N/W c | 125 n | | with ECMP c | 126 n | | c | 127 +---+---+ | | c | 128 | | | | c | 129 | S-PE1 +ccccccccccccccccccccccccccc+ / 130 | | | \ ^ / 131 +-------+ | -------------|----------- 132 | | 133 | | 134 | | 135 PW Segment PW Segment 136 (w/o CW) over with CW 137 LSP w/o ECMP 139 Reference Network 141 In Figure 1, T-PE1 is a device which is not capable of including a 142 CW in Ethernet PW encapsulation, T-PE2 is a device which is capable 143 to use the CW for Ethernet PW encapsulation, while S-PE1 is the new 144 type of device defined in this document. 146 S-PE1 can be added to the network with minimum or no service 147 disruption and PW redundancy [RFC 6718] or [RFC 7771] can be used to 148 move the traffic from the old single-segment PW (SS-PW) without the 149 CW to the new multi-segment PW (MS-PW) with the CW on the PW segment 150 that passes through the MPLS network. 152 1.1. Assumptions 154 This document assumes that T-PE1 operates in the same way regardless 155 of whether the PW is a SS-PW or a MS-PW, as defined in [RFC 6073]: 157 o T-PE1 signals SS-PW with T-PE2 using T-LDP, as defined in [RFC 158 4447] 160 o T-PE1 could be configured to signal a PW segment with S-PE1, as 161 if it were T-PE2 using T-LDP, following the procedures defined in 162 [RFC 6073]. 164 o T-PE1 is capable to set the PW-TTL value (i.e., the TTL value of 165 the PW LSE) for Ethernet PW packets to a proper value that allows 166 the Ethernet frames to be forwarded on the AC on T-PE2 (e.g., PW- 167 TTL>2 in Figure 1): this could be done either via administrative 168 configuration or though T-LDP information. 170 It is also assumed that if T-PE1 supports Pseudowire Virtual Circuit 171 Connectivity Verification (VCCV), it can support at least CC Type 3 172 or CC Type 4. The underlying rationale for this assumption is that 173 use of CC Type 2 for MS-PW is not allowed in [RFC 6073]. 175 If T-PE1 supports CC Type 3, it is assumed that it is capable to set 176 the PW-TTL value for the VCCV packets to a proper value that allows 177 the VCCV packets to be recognized by T-PE2 by PW-TTL expiry (e.g., 178 PW-TTL=2): this could be done either via administrative 179 configuration or though T-LDP information. 181 It is assumed that S-PE1 is manually configured to switch between 182 the two PW segments, following the procedure described in [RFC 183 6073]. 185 If T-PE2 supports VCCV, it is configured to always advertise support 186 for CC type 1. This would allow simplifying the VCCV switching 187 process since CC type 1 is always used on the PW segment with CW. 189 2. Terminology 191 This document re-uses the terminology defined in [RFC 6073] for 192 single-segment pseudo-wire (SS-PW), multi-segment PW (MS-PW), 193 terminating provider edge (T-PE) and switching provider edge (S-PE). 195 This document uses the acronym PW-TTL to indicate the TTL value in 196 the PW label stack entry (LSE). 198 2.1. Conventions Used in This Document 200 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 202 "OPTIONAL" in this document are to be interpreted as described in 203 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 204 capitals, as shown here. 206 3. Control Word Stitching procedures 208 The CW stitching procedure is performed by the S-PE1 on the Ethernet 209 PW packets it is forwarding. 211 With a reference to Figure 1, it performs the following operations, 212 in the direction from T-PE1 to T-PE2: 214 1. It pops the MPLS label stack entry (LSE) of the LSP from T-PE1 to 215 S-PE1, if not PHP-ed by the penultimate LSR 217 2. It swaps the PW label (and decrements the PW-TTL) 219 3. It adds the CW immediately following the bottom of the label 220 stack 222 4. It pushes the MPLS LSE for the LSP to T-PE2, unless this LSP is a 223 single-hop PHP-ed LSP. 225 It is worth noting that step 3 is the only addition to the S-PE 226 forwarding rules defined in [RFC 6073]. 228 In the opposite direction, S-PE1 performs the following operations: 230 1. It pops the MPLS label stack entry (LSE) for the LSP from T-PE2 231 to S-PE1, if not PHP-ed by the penultimate LSR 233 2. It swaps the PW label (and decrements the PW-TTL) 235 3. It removes the CW, which is located immediately following the 236 bottom of the label stack 238 4. It pushes the MPLS LSE for the LSP to T-PE2, unless this LSP is a 239 single-hop PHP-ed LSP. 241 It is worth noting that step 3 is the only addition to the S-PE 242 forwarding rules defined in [RFC 6073]. 244 3.1. CW Stitching Signaling 246 S-PE1 negotiates CW capabilities with T-PE1 and T-PE2 following 247 almost the same procedures defined in [RFC 4447] and [RFC 6073]. 249 The only exception to the procedures defined in [RFC 6073] is that 250 S-PE1, when signaling one PW segment, will always behave as if the 251 CW is supported on the other PW segment. 253 This allows S-PE1 to negotiate different CW capabilities on 254 different PW segments as well as to enable CW toward any T-PE that 255 support CW insertion. 257 If the same CW capabilities are negotiated on both PW segments, then 258 S-PE1 will behave as specified in [RFC 6073]. CW stitching, as 259 defined in this document, is enabled if and only if different CW 260 capabilities are negotiated on the two PW segments. 262 PW Seg't PW Seg't 263 (no CW) (with CW) 264 | | 265 +-------+ | +-------+ | +-------+ 266 | |==== V ====| |==== V ====| | 267 | T-PE1 +-----------+ S-PE1 +-----------+ T-PE2 | 268 | |===========| |===========| | 269 +-------+ LSP1 +-------+ LSP2 +-------+ 271 C=0 C=1 272 -----------> ----------> 274 [C=1 ->] C=0 C=1 275 <----------- <---------- 277 CW Stitching Signaling 279 Figure 2 shows an example of how CW capabilities are negotiated in 280 the reference network scenario of Figure 1. 282 T-PE1 will send a T-LDP Label Mapping message with c=0 and T-PE2 283 will send a T-LDP Label Mapping message with C=1, following the 284 procedures defined in section 6.2 of [RFC 4447] and amended by [I-D 285 ETH-CW]. 287 After S-PE1 receives the T-LDP Label Mapping message (with c=1) from 288 T-PE2, it can send a T-LDP Label Mapping message back to T-PE2 (with 289 c=1), following the procedures defined in section 6.2 of [RFC 4447], 290 and a T-LDP Label Mapping messages to T-PE1 (with c=1), following 291 the procedures of [RFC 6073]. 293 After S-PE1 receives the T-LDP Label Mapping message (with c=0) from 294 T-PE1, it can send a T-LDP Label Mapping message to T-PE2 (with 295 c=1), as if it has received c=1 from T-PE1. It can also send a T-LDP 296 Label Mapping message back to T-PE1 with c=0, following the 297 procedures defined in section 6.2 of [RFC 4447]. 299 If S-PE1 receives the T-LDP Label Mapping message (with c=0) from T- 300 PE1 after having sent a T-LDP Label Mapping message with c=1 to T- 301 PE1, a Label Withdraw message needs to be sent to T-PE1 before 302 sending another Label Mapping message with c=1, as specified in 303 section 6.2 of [RFC 4447]. 305 When the MS-PW is completely setup: 307 o T-PE1 is configured not to insert CW 309 o T-PE2 is configures to insert CW 311 o S-PE1 is configured to stitch the CW between the two PW segments 313 4. VCCV Stitching Procedures 315 When CW stitching is enabled, VCCV packets sent on the two PW 316 segments would have different formats. In order to enable end-to-end 317 OAM, S-PE1 needs to be capable to perform VCCV stitching. 319 Since support of CC Type 1 is REQUIRED by [RFC 5085] for PWs that 320 support the CW, within this document it is RECOMMENDED that its use 321 is always enabled at the T-PEs supporting the CW (e.g., T-PE2) such 322 that, following the rules defined in [RFC 5085], when VCCV is in 323 use, CC Type 1 is always used on the PW segment that support the CW. 325 Since [RFC 5085] does not define any mandatory CC Types for the PWs 326 that do not support CW, different VCCV stitching procedures need to 327 be defined depending on the CC Type supported by the T-PE not 328 supporting the CW (e.g., T-PE1). 330 The VCCV stitching procedure is performed by S-PE1 on the VCCV 331 packets it is forwarding. 333 In the traffic direction from T-PE2 and T-PE1 CC Type 1 is used: S- 334 PE1 can distinguish VCCV and Ethernet PW packets by looking at the 335 first nibble immediately following the bottom of the label stack 336 which identifies either an ACH or a CW: 338 o Ethernet PW packets are received with the CW: these packets need 339 to be forwarded following the rules defined in section 3. 341 o VCCV packets targeted at S-PE1 are received with the ACH and the 342 PW-TTL=1: these packets should be processed by S-PE1 and not 343 forwarded. 345 o Other VCCV packets are received with the ACH and with a PW-TTL 346 value greater than 1: these packets need to be forwarded 347 following the rules defined in the following sections. 349 In the traffic direction from T-PE1 and T-PE2, the rules used to 350 distinguish VCCV packets from Ethernet PW packets depends from the 351 CC Type used on the PW segment without the CW. 353 4.1. VCCV Stitching for CC Type 3 355 In case CC Type 3 is used on the PW segment not using the CW, VCCV 356 stitching needs to translate between CC Type 3 (without the CW) and 357 CC Type 1. It is worth noting that when CC Type 3 is used on PW 358 segments not using the CW, only IP-based CV types can be supported. 360 In the traffic direction from T-PE1 and T-PE2, S-PE1 can distinguish 361 VCCV and Ethernet PW packets by looking at the PW-TTL value: 363 o Ethernet PW packets are received with a PW-TTL value exceeding 364 the PW-TTL distance from S-PE1 to T-PE2 (e.g., TTL>2): these 365 packets need to be forwarded following the rules defined in 366 section 3. 368 o VCCV packets targeted at S-PE1 are received with PW-TTL=1: these 369 packets should be processed by S-PE1 and not forwarded. 371 o Other VCCV packets are received with a PW-TTL value greater than 372 1 and not exceeding the PW-TTL distance to T-PE2 (e.g., TTL=2): 373 these packets need to be forwarded following the rules defined in 374 this section. 376 With a reference to Figure 1, S-PE1 performs the following 377 operations, in the direction from T-PE1 to T-PE2: 379 1. It pops the MPLS label stack entry (LSE) of the LSP from T-PE1 to 380 S-PE1, if not PHP-ed by the penultimate LSR 382 2. It swaps the PW label (and decrements the PW-TTL) 384 3. It adds the ACH immediately following the bottom of the label 385 stack (setting the ACH Channel Type based on the IP version field 386 of the encapsulated IP packet) 388 4. It pushes the MPLS LSE for the LSP to T-PE2, unless this LSP is a 389 single-hop PHP-ed LSP. 391 It is worth noting that step 3 is the only addition to the S-PE 392 forwarding rules defined in [RFC 6073]: it is also the only step 393 where the forwarding rules of VCCV packets are different from the 394 forwarding rules defined for Ethernet PW packets in section 3. 396 S-PE1 can understand the IP version field of the encapsulated IP 397 packet by looking at the first nibble immediately following the 398 bottom of the label stack of the received packet. 400 In the opposite direction, S-PE1 performs the following operations: 402 1. It pops the MPLS label stack entry (LSE) for the LSP from T-PE2 403 to S-PE1, if not PHP-ed by the penultimate LSR 405 2. It swaps the PW label (and decrements the PW-TTL) 407 3. It removes the ACH, which is located immediately following the 408 bottom of the label stack 410 4. It pushes the MPLS LSE for the LSP to T-PE2, unless this LSP is a 411 single-hop PHP-ed LSP. 413 It is worth noting that step 3 is the only addition to the S-PE 414 forwarding rules defined in [RFC 6073]: it is also the only step 415 where the forwarding rules of VCCV packets are different from the 416 forwarding rules defined for Ethernet PW packets in section 3. 418 4.2. VCCV Stitching for CC Type 4 420 In case CC Type 4 is used on the PW segment not using the CW, VCCV 421 stitching needs to translate between CC Type 4 and CC Type 1. It is 422 worth noting that in this case both IP-based and ACH-based CV types 423 can be supported. 425 In the traffic direction from T-PE1 and T-PE2, S-PE1 can distinguish 426 VCCV and Ethernet PW packets by looking at GAL LSE right after the 427 PW LSE: 429 o Ethernet PW packets are received without a GAL LSE: these packets 430 need to be forwarded following the rules defined in section 3. 432 o VCCV packets targeted at S-PE1 are received with the GAL LSE and 433 with the PW-TTL=1: these packets should be processed by S-PE1 and 434 not forwarded. 436 o Other VCCV packets are received with the GAL LSE and with a PW- 437 TTL value greater than 1: these packets need to be forwarded 438 following the rules defined in this section. 440 With a reference to Figure 1, S-PE1 performs the following 441 operations, in the direction from T-PE1 to T-PE2: 443 1. It pops the MPLS label stack entry (LSE) of the LSP from T-PE1 to 444 S-PE1, if not PHP-ed by the penultimate LSR 446 2. It swaps the PW label (and decrements the PW-TTL) 448 3. It removes the GAL LSE at the bottom of the label stack 450 4. It sets the S-bit of the PW LSE since the PW LSE becomes the new 451 bottom of the label stack 453 5. It pushes the MPLS LSE for the LSP to T-PE2, unless this LSP is a 454 single-hop PHP-ed LSP. 456 It is worth noting that steps 3 and 4 are the only additions to the 457 S-PE forwarding rules defined in [RFC 6073]: they are also the only 458 steps where the forwarding rules of VCCV packets are different from 459 the forwarding rules defined for Ethernet PW packets in section 3. 461 In the opposite direction, S-PE1 performs the following operations: 463 1. It pops the MPLS label stack entry (LSE) for the LSP from T-PE2 464 to S-PE1, if not PHP-ed by the penultimate LSR 466 2. It swaps the PW label (and decrements the PW-TTL) 468 3. It inserts the GAL LSE at the bottom of the label stack 470 4. It clears the S-bit of the PW LSE since the PW LSE is no longer 471 at the bottom of the label stack 473 5. It pushes the MPLS LSE for the LSP to T-PE2, unless this LSP is a 474 single-hop PHP-ed LSP. 476 It is worth noting that steps 3 and 4 are the only additions to the 477 S-PE forwarding rules defined in [RFC 6073]: they are also the only 478 steps where the forwarding rules of VCCV packets are different from 479 the forwarding rules defined for Ethernet PW packets in section 3. 481 4.3. VCCV Stitching Signaling 483 S-PE1 negotiates VCCV capabilities with T-PE1 and T-PE2 following 484 almost the same procedures defined in [RFC 5085] and [RFC 6073]. 486 If the same CW capabilities are negotiated on both PW segments, then 487 S-PE1 will behave as specified in [RFC 6073]. VCCV stitching, as 488 defined in this document, is enabled if and only if different CW 489 capabilities are negotiated on the two PW segments. 491 If S-PE1 supports VCCV stitching for CC Type 3, and it knows the PW- 492 TTL distance to both T-PE1 and T-PE2: 494 o If T-PE1 advertises support for CC Type 3, S-PE1 advertises 495 support for CC Type 1 to T-PE2 497 o If T-PE2 advertises support for CC Type 1, S-PE1 behaves toward 498 T-PE1 if it supports CC Type 3 and T-PE2 has advertised support 499 for CC Type 3, following the procedure defined in [RFC 6073] 501 If S-PE1 supports VCCV stitching for CC Type 4: 503 o If T-PE1 advertises support for CC Type 4, S-PE1 advertises 504 support for CC Type 1 to T-PE2 506 o If T-PE2 advertises support for CC Type 1, S-PE1 behaves toward 507 T-PE1 as if it supports CC Type 4 and T-PE2 has advertised 508 support for CC Type 4, following the procedure defined in [RFC 509 6073] 511 CV types are advertised based on S-PE1 capabilities as per [RFC 512 6073] with the following additional rule: 514 o S-PE1 can advertise support for ACH-based CV types if and only if 515 it supports VCCV stitching for CC Type 4 517 This rule ensures that only IP-based CV types are negotiated between 518 T-PE1, T-PE2 and S-PE1 when VCCV stitching for CC Type 3 is used. 520 If T-PE1 supports CC Type 4 and S-PE1 supports VCCV stitching for CC 521 Type 4, then VCCV stitching for CC Type 4 is used and both IP-based 522 and ACH-based CV capabilities can be negotiated depending on T-PE1, 523 T-PE2 and S-PE1 CV capabilities. 525 If T-PE1 does not support CC Type 4, it will advertise support only 526 for IP-based CV types and therefore only IP-based CV capabilities 527 can be negotiated depending on T-PE1, T-PE2 and S-PE1 CV 528 capabilities. 530 If S-PE1 does not support VCCV stitching for CC Type 4, it will 531 advertise support only for IP-based CV types and therefore only IP- 532 based CV capabilities can be negotiated depending on T-PE1, T-PE2 533 and S-PE1 CV capabilities. 535 5. Other Deployment Scenarios 537 The solution described in this document is quite generic and can be 538 used in different deployment scenarios, in addition to the reference 539 network outline in Figure 1, without requiring any change to the 540 behavior of the S-PE, as defined in this document. 542 A possible deployment scenario is shows in Figure 3 where both T-PEs 543 are not capable to insert the CW: 545 Original SS-PW 546 (w/o CW) 547 | 548 +-------+ /--------|----------------\ +-------+ 549 | | / V \ | | 550 | T-PE1 +ooooooooooooooooooooooooooooooooooooooooo+ T-PE2 | 551 | | | | | | 552 +---+---+ | | +---+---+ 553 n | | n 554 n<-----+ | MPLS N/W | n<-----+ 555 n | | with ECMP | n | 556 n | | | n | 557 +---+---+ | | | +---+---+ | 558 | | | | | | | | 559 | S-PE1 +ccccccccccccccccccccccccccccccccccccccccc+ S-PE2 | | 560 | | | \ ^ / | | | 561 +-------+ | -------------|----------- +-------+ | 562 | | | 563 | | | 564 | | | 565 PW Segment PW Segment PW Segment 566 (w/o CW) over with CW (w/o CW) over 567 LSP w/o ECMP LSP w/o ECMP 569 Reference network with two T-PEs not capable to insert CW 571 In this scenario, two S-PEs needs to be deployed: S-PE1 in front of 572 T-PE1 and S-PE2 in front of T-PE2. 574 S-PE1 and S-PE2 operate as defined in this document: these 575 operations are the same even if one or both the PW segments switched 576 by one S-PE are terminated at a T-PE or at another S-PE. 578 An even more generic deployment scenario is shows in Figure 3: 580 T-PE1 S-PE1 S-PE2 S-PE3 S-PE4 T-PE2 581 +---+ +---+ +---+ +---+ +---+ +---+ 582 | | | | | | | | | | | | 583 | +nnnnnn+ +nnnnnn+ +cccccc+ +cccccc+ +nnnnnn+ | 584 | | ^ | | | | ^ | | | | | | 585 +---+ | +---+ +---+ | +---+ +---+ +---+ 586 | | 587 | | 588 PW Seg't PW Seg't 589 (no CW) over with CW over 590 LSP no ECMP LSP with or 591 without ECMP 593 More generic Reference network 595 In this case a MS-PW can be setup with some PW segments using the CW 596 and other not using the CW. 598 S-PE1 and S-PE3 operates as defined in [RFC 6073] while S-PE2 and S- 599 PE4 operate as defined in this document: these operations are the 600 same even if one or both the PW segments switched by one S-PE are 601 terminated at a T-PE or at another S-PE operating as defined in [RFC 602 6073] or at another S-PE operating as defined in this document. 604 The operations are also the same if the PW segment not using the CW 605 is setup over a link or over an MPLS network. 607 In order to achieve the desired behavior, i.e., to avoid the issues 608 described in [I-D ETH-CW], care must be taken by the operator to 609 make sure that no ECMP is used within the MPLS network carrying the 610 PW segments without the CW. 612 The operations described in this document work also if static 613 configuration is used instead of T-LDP to setup some or all the PW 614 segments. 616 The operations described in this document work also if dynamic MS-PW 617 signaling procedures, as defined in [RFC7267], are used instead of 618 static configuration of the S-PEs. 620 6. Security Considerations 622 The method described in this document adds no security issues beyond 623 those encountered in a network running multi-segment Ethernet 624 pseudowires with the Control Word over MPLS, as previously discussed 625 in [RFC4385], [RFC4448] and [RFC7267]. Such networks are normally 626 private, well managed, highly controlled environments. 628 7. IANA Considerations 630 This document makes no IANA requests. 632 8. References 634 8.1. Normative References 636 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 637 Requirement Levels", BCP 14, RFC 2119, March 1997. 639 [RFC4385] Bryant, S. et al., "Pseudowire Emulation Edge-to-Edge 640 (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, 641 February 2006. 643 [RFC4447] Martini, L. et al., "Pseudowire Setup and Maintenance 644 Using the Label Distribution Protocol (LDP)", RFC 4447, 645 April 2006. 647 [RFC4448] Martini, L. et al., "Encapsulation Methods for Transport 648 of Ethernet over MPLS Networks", RFC 4448, April 2006. 650 [RFC5085] Nadeu, T., Pignataro, C., " Pseudowire Virtual Circuit 651 Connectivity Verification (VCCV): A Control Channel for 652 Pseudowires", RFC 5085, December 2007. 654 [RFC6073] Martini, L. et al., "Segmented Pseudowire", RFC 6073, 655 January 2011. 657 [RFC7267] Martini, L. et al., "Dynamic Placement of Multi-Segment 658 Pseudowires", RFC 7267, June 2014. 660 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 661 2119 Key Words", BCP 14, RFC 8174, May 2017. 663 [I-D ETH-CW] Bryant, S. et al., "Use of Ethernet Control Word 664 RECOMMENDED", draft-ietf-pals-ethernet-cw, work in 665 progress. 667 8.2. Informative References 669 [RFC6718] Muley, P. et al., "Pseudowire Redundancy", RFC 6718, 670 August 2012. 672 [RFC7771] Malis, A. et al., "Switching Provider Edge (S-PE) 673 Protection for MPLS and MPLS Transport Switching Provider 674 Edge (S-PE) Protection for MPLS and MPLS Transport", RFC 675 7771, January 2016. 677 9. Acknowledgments 679 This document was prepared using 2-Word-v2.0.template.dot. 681 Authors' Addresses 683 Italo Busi 684 Huawei 686 Email: italo.busi@huawei.com 688 Stewart Bryant 689 Huawei 691 Email: stewart.bryant@gmail.com 693 Andrew G. Malis 694 Huawei 696 Email: agmalis@gmail.com 698 Jie Dong 699 Huawei 701 Email: jie.dong@huawei.com