idnits 2.17.00 (12 Aug 2021) /tmp/idnits49121/draft-busi-pals-pw-cw-stitching-01.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 (October 22, 2018) is 1300 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 618, 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 323, but not defined ** Obsolete undefined reference: RFC 4447 (Obsoleted by RFC 8077) == Missing Reference: 'RFC 5085' is mentioned on line 503, but not defined == Unused Reference: 'RFC5085' is defined on line 670, but no explicit reference was found in the text == Unused Reference: 'RFC6073' is defined on line 674, but no explicit reference was found in the text == Unused Reference: 'RFC6718' is defined on line 689, but no explicit reference was found in the text == Unused Reference: 'RFC7771' is defined on line 692, 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 (~~), 13 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: April 2019 Jie Dong 5 Huawei 7 October 22, 2018 9 Pseudowire (PW) Control Word (CW) Stitching 10 draft-busi-pals-pw-cw-stitching-01.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 April 22, 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...............................................5 69 2. Terminology....................................................5 70 2.1. Conventions Used in This Document.........................6 71 3. Control Word Stitching procedures..............................6 72 3.1. CW Stitching Signaling....................................7 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...........................................16 80 8. References....................................................16 81 8.1. Normative References.....................................16 82 8.2. Informative References...................................16 83 9. Acknowledgments...............................................17 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 There are cases where service providers have existing deployments 93 where the Provider Edge (PE) device is an old piece of equipment 94 which does not support the CW for Ethernet PW encapsulation. In this 95 case, the CW shall not 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 Figure 1 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 The deployment of the S-PE1, either as a new router or as an upgrade 153 of an existing router, does not require any changes/upgrades to 154 other nodes already installed within the network. 156 It is expected that in new deployments, all the Provider Edge (PE) 157 devices are capable to insert the CW for Ethernet PW encapsulation 158 and therefore the solution described in this document mainly applies 159 to existing deployments where there are old pieces of equipment not 160 being capable to support the CW for Ethernet PW encapsulation. 162 1.1. Assumptions 164 This document assumes that T-PE1 operates in the same way regardless 165 of whether the PW is a SS-PW or a MS-PW, as defined in [RFC 6073]: 167 o T-PE1 signals SS-PW with T-PE2 using T-LDP, as defined in [RFC 168 4447] 170 o T-PE1 could be configured to signal a PW segment with S-PE1, as 171 if it were T-PE2 using T-LDP, following the procedures defined in 172 [RFC 6073]. 174 o T-PE1 is capable to set the PW-TTL value (i.e., the TTL value of 175 the PW LSE) for Ethernet PW packets to a proper value that allows 176 the Ethernet frames to be forwarded on the AC on T-PE2 (e.g., PW- 177 TTL>2 in Figure 1): this could be done either via administrative 178 configuration or though T-LDP information. 180 It is also assumed that if T-PE1 supports Pseudowire Virtual Circuit 181 Connectivity Verification (VCCV), it can support at least CC Type 3 182 or CC Type 4. The underlying rationale for this assumption is that 183 use of CC Type 2 for MS-PW is not allowed in [RFC 6073]. 185 If T-PE1 supports CC Type 3, it is assumed that it is capable to set 186 the PW-TTL value for the VCCV packets to a proper value that allows 187 the VCCV packets to be recognized by T-PE2 by PW-TTL expiry (e.g., 188 PW-TTL=2): this could be done either via administrative 189 configuration or though T-LDP information. 191 It is assumed that S-PE1 is manually configured to switch between 192 the two PW segments, following the procedure described in [RFC 193 6073]. 195 If T-PE2 supports VCCV, it is configured to always advertise support 196 for CC type 1. This would allow simplifying the VCCV switching 197 process since CC type 1 is always used on the PW segment with CW. 199 2. Terminology 201 This document re-uses the terminology defined in [RFC 6073] for 202 single-segment pseudo-wire (SS-PW), multi-segment PW (MS-PW), 203 terminating provider edge (T-PE) and switching provider edge (S-PE). 205 This document uses the acronym PW-TTL to indicate the TTL value in 206 the PW label stack entry (LSE). 208 2.1. Conventions Used in This Document 210 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 211 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 212 "OPTIONAL" in this document are to be interpreted as described in 213 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 214 capitals, as shown here. 216 3. Control Word Stitching procedures 218 The CW stitching procedure is performed by the S-PE1 on the Ethernet 219 PW packets it is forwarding. 221 With a reference to Figure 1, it performs the following operations, 222 in the direction from T-PE1 to T-PE2: 224 1. It pops the MPLS label stack entry (LSE) of the LSP from T-PE1 to 225 S-PE1, if not PHP-ed by the penultimate LSR 227 2. It swaps the PW label (and decrements the PW-TTL) 229 3. It adds the CW immediately following the bottom of the label 230 stack 232 4. It pushes the MPLS LSE for the LSP to T-PE2, unless this LSP is a 233 single-hop PHP-ed LSP. 235 It is worth noting that step 3 is the only addition to the S-PE 236 forwarding rules defined in [RFC 6073]. 238 In this step, the S-PE inserts also the sequence number field in the 239 control word, following the rules defined in [RFC4448]. 241 In the opposite direction, S-PE1 performs the following operations: 243 1. It pops the MPLS label stack entry (LSE) for the LSP from T-PE2 244 to S-PE1, if not PHP-ed by the penultimate LSR 246 2. It swaps the PW label (and decrements the PW-TTL) 248 3. It removes the CW, which is located immediately following the 249 bottom of the label stack 251 4. It pushes the MPLS LSE for the LSP to T-PE2, unless this LSP is a 252 single-hop PHP-ed LSP. 254 It is worth noting that step 3 is the only addition to the S-PE 255 forwarding rules defined in [RFC 6073]. 257 In this step, the S-PE MAY also process the sequence number field in 258 the control word, following the rules defined in [RFC4448]. 260 3.1. CW Stitching Signaling 262 S-PE1 negotiates CW capabilities with T-PE1 and T-PE2 following 263 almost the same procedures defined in [RFC 4447] and [RFC 6073]. 265 The only exception to the procedures defined in [RFC 6073] is that 266 S-PE1, when signaling one PW segment, will always behave as if the 267 CW is supported on the other PW segment. 269 This allows S-PE1 to negotiate different CW capabilities on 270 different PW segments as well as to enable CW toward any T-PE that 271 support CW insertion. 273 If the same CW capabilities are negotiated on both PW segments, then 274 S-PE1 will behave as specified in [RFC 6073]. CW stitching, as 275 defined in this document, is enabled if and only if different CW 276 capabilities are negotiated on the two PW segments. 278 In case the S-PE considers the sequence number field in the control 279 word, it SHALL follow the rules described in section 6.4 of 280 [RFC4447]. 282 PW Seg't PW Seg't 283 (no CW) (with CW) 284 | | 285 +-------+ | +-------+ | +-------+ 286 | |==== V ====| |==== V ====| | 287 | T-PE1 +-----------+ S-PE1 +-----------+ T-PE2 | 288 | |===========| |===========| | 289 +-------+ LSP1 +-------+ LSP2 +-------+ 291 C=0 C=1 292 -----------> ----------> 294 [C=1 ->] C=0 C=1 295 <----------- <---------- 297 Figure 2 CW Stitching Signaling 299 Figure 2 shows an example of how CW capabilities are negotiated in 300 the reference network scenario of Figure 1. 302 T-PE1 will send a T-LDP Label Mapping message with c=0 and T-PE2 303 will send a T-LDP Label Mapping message with C=1, following the 304 procedures defined in section 6.2 of [RFC 4447] and amended by [I-D 305 ETH-CW]. 307 After S-PE1 receives the T-LDP Label Mapping message (with c=1) from 308 T-PE2, it can send a T-LDP Label Mapping message back to T-PE2 (with 309 c=1), following the procedures defined in section 6.2 of [RFC 4447], 310 and a T-LDP Label Mapping messages to T-PE1 (with c=1), following 311 the procedures of [RFC 6073]. 313 After S-PE1 receives the T-LDP Label Mapping message (with c=0) from 314 T-PE1, it can send a T-LDP Label Mapping message to T-PE2 (with 315 c=1), as if it has received c=1 from T-PE1. It can also send a T-LDP 316 Label Mapping message back to T-PE1 with c=0, following the 317 procedures defined in section 6.2 of [RFC 4447]. 319 If S-PE1 receives the T-LDP Label Mapping message (with c=0) from T- 320 PE1 after having sent a T-LDP Label Mapping message with c=1 to T- 321 PE1, a Label Withdraw message needs to be sent to T-PE1 before 322 sending another Label Mapping message with c=1, as specified in 323 section 6.2 of [RFC 4447]. 325 When the MS-PW is completely setup: 327 o T-PE1 is configured not to insert CW 329 o T-PE2 is configures to insert CW 331 o S-PE1 is configured to stitch the CW between the two PW segments 333 4. VCCV Stitching Procedures 335 When CW stitching is enabled, VCCV packets sent on the two PW 336 segments would have different formats. In order to enable end-to-end 337 OAM, S-PE1 needs to be capable to perform VCCV stitching. 339 Since support of CC Type 1 is REQUIRED by [RFC 5085] for PWs that 340 support the CW, within this document it is RECOMMENDED that its use 341 is always enabled at the T-PEs supporting the CW (e.g., T-PE2) such 342 that, following the rules defined in [RFC 5085], when VCCV is in 343 use, CC Type 1 is always used on the PW segment that support the CW. 345 Since [RFC 5085] does not define any mandatory CC Types for the PWs 346 that do not support CW, different VCCV stitching procedures need to 347 be defined depending on the CC Type supported by the T-PE not 348 supporting the CW (e.g., T-PE1). 350 The VCCV stitching procedure is performed by S-PE1 on the VCCV 351 packets it is forwarding. 353 In the traffic direction from T-PE2 and T-PE1 CC Type 1 is used: S- 354 PE1 can distinguish VCCV and Ethernet PW packets by looking at the 355 first nibble immediately following the bottom of the label stack 356 which identifies either an ACH or a CW: 358 o Ethernet PW packets are received with the CW: these packets need 359 to be forwarded following the rules defined in section 3. 361 o VCCV packets targeted at S-PE1 are received with the ACH and the 362 PW-TTL=1: these packets should be processed by S-PE1 and not 363 forwarded. 365 o Other VCCV packets are received with the ACH and with a PW-TTL 366 value greater than 1: these packets need to be forwarded 367 following the rules defined in the following sections. 369 In the traffic direction from T-PE1 and T-PE2, the rules used to 370 distinguish VCCV packets from Ethernet PW packets depends from the 371 CC Type used on the PW segment without the CW. 373 4.1. VCCV Stitching for CC Type 3 375 In case CC Type 3 is used on the PW segment not using the CW, VCCV 376 stitching needs to translate between CC Type 3 (without the CW) and 377 CC Type 1. It is worth noting that when CC Type 3 is used on PW 378 segments not using the CW, only IP-based CV types can be supported. 380 In the traffic direction from T-PE1 and T-PE2, S-PE1 can distinguish 381 VCCV and Ethernet PW packets by looking at the PW-TTL value: 383 o Ethernet PW packets are received with a PW-TTL value exceeding 384 the PW-TTL distance from S-PE1 to T-PE2 (e.g., TTL>2): these 385 packets need to be forwarded following the rules defined in 386 section 3. 388 o VCCV packets targeted at S-PE1 are received with PW-TTL=1: these 389 packets should be processed by S-PE1 and not forwarded. 391 o Other VCCV packets are received with a PW-TTL value greater than 392 1 and not exceeding the PW-TTL distance to T-PE2 (e.g., TTL=2): 393 these packets need to be forwarded following the rules defined in 394 this section. 396 With a reference to Figure 1, S-PE1 performs the following 397 operations, in the direction from T-PE1 to T-PE2: 399 1. It pops the MPLS label stack entry (LSE) of the LSP from T-PE1 to 400 S-PE1, if not PHP-ed by the penultimate LSR 402 2. It swaps the PW label (and decrements the PW-TTL) 404 3. It adds the ACH immediately following the bottom of the label 405 stack (setting the ACH Channel Type based on the IP version field 406 of the encapsulated IP packet) 408 4. It pushes the MPLS LSE for the LSP to T-PE2, unless this LSP is a 409 single-hop PHP-ed LSP. 411 It is worth noting that step 3 is the only addition to the S-PE 412 forwarding rules defined in [RFC 6073]: it is also the only step 413 where the forwarding rules of VCCV packets are different from the 414 forwarding rules defined for Ethernet PW packets in section 3. 416 S-PE1 can understand the IP version field of the encapsulated IP 417 packet by looking at the first nibble immediately following the 418 bottom of the label stack of the received packet. 420 In the opposite direction, S-PE1 performs the following operations: 422 1. It pops the MPLS label stack entry (LSE) for the LSP from T-PE2 423 to S-PE1, if not PHP-ed by the penultimate LSR 425 2. It swaps the PW label (and decrements the PW-TTL) 427 3. It removes the ACH, which is located immediately following the 428 bottom of the label stack 430 4. It pushes the MPLS LSE for the LSP to T-PE2, unless this LSP is a 431 single-hop PHP-ed LSP. 433 It is worth noting that step 3 is the only addition to the S-PE 434 forwarding rules defined in [RFC 6073]: it is also the only step 435 where the forwarding rules of VCCV packets are different from the 436 forwarding rules defined for Ethernet PW packets in section 3. 438 4.2. VCCV Stitching for CC Type 4 440 In case CC Type 4 is used on the PW segment not using the CW, VCCV 441 stitching needs to translate between CC Type 4 and CC Type 1. It is 442 worth noting that in this case both IP-based and ACH-based CV types 443 can be supported. 445 In the traffic direction from T-PE1 and T-PE2, S-PE1 can distinguish 446 VCCV and Ethernet PW packets by looking at GAL LSE right after the 447 PW LSE: 449 o Ethernet PW packets are received without a GAL LSE: these packets 450 need to be forwarded following the rules defined in section 3. 452 o VCCV packets targeted at S-PE1 are received with the GAL LSE and 453 with the PW-TTL=1: these packets should be processed by S-PE1 and 454 not forwarded. 456 o Other VCCV packets are received with the GAL LSE and with a PW- 457 TTL value greater than 1: these packets need to be forwarded 458 following the rules defined in this section. 460 With a reference to Figure 1, S-PE1 performs the following 461 operations, in the direction from T-PE1 to T-PE2: 463 1. It pops the MPLS label stack entry (LSE) of the LSP from T-PE1 to 464 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 removes the GAL LSE at the bottom of the label stack 470 4. It sets the S-bit of the PW LSE since the PW LSE becomes the new 471 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 In the opposite direction, S-PE1 performs the following operations: 483 1. It pops the MPLS label stack entry (LSE) for the LSP from T-PE2 484 to S-PE1, if not PHP-ed by the penultimate LSR 486 2. It swaps the PW label (and decrements the PW-TTL) 488 3. It inserts the GAL LSE at the bottom of the label stack 489 4. It clears the S-bit of the PW LSE since the PW LSE is no longer 490 at the bottom of the label stack 492 5. It pushes the MPLS LSE for the LSP to T-PE2, unless this LSP is a 493 single-hop PHP-ed LSP. 495 It is worth noting that steps 3 and 4 are the only additions to the 496 S-PE forwarding rules defined in [RFC 6073]: they are also the only 497 steps where the forwarding rules of VCCV packets are different from 498 the forwarding rules defined for Ethernet PW packets in section 3. 500 4.3. VCCV Stitching Signaling 502 S-PE1 negotiates VCCV capabilities with T-PE1 and T-PE2 following 503 almost the same procedures defined in [RFC 5085] and [RFC 6073]. 505 If the same CW capabilities are negotiated on both PW segments, then 506 S-PE1 will behave as specified in [RFC 6073]. VCCV stitching, as 507 defined in this document, is enabled if and only if different CW 508 capabilities are negotiated on the two PW segments. 510 If S-PE1 supports VCCV stitching for CC Type 3, and it knows the PW- 511 TTL distance to both T-PE1 and T-PE2: 513 o If T-PE1 advertises support for CC Type 3, S-PE1 advertises 514 support for CC Type 1 to T-PE2 516 o If T-PE2 advertises support for CC Type 1, S-PE1 behaves toward 517 T-PE1 if it supports CC Type 3 and T-PE2 has advertised support 518 for CC Type 3, following the procedure defined in [RFC 6073] 520 If S-PE1 supports VCCV stitching for CC Type 4: 522 o If T-PE1 advertises support for CC Type 4, S-PE1 advertises 523 support for CC Type 1 to T-PE2 525 o If T-PE2 advertises support for CC Type 1, S-PE1 behaves toward 526 T-PE1 as if it supports CC Type 4 and T-PE2 has advertised 527 support for CC Type 4, following the procedure defined in [RFC 528 6073] 530 CV types are advertised based on S-PE1 capabilities as per [RFC 531 6073] with the following additional rule: 533 o S-PE1 can advertise support for ACH-based CV types if and only if 534 it supports VCCV stitching for CC Type 4 536 This rule ensures that only IP-based CV types are negotiated between 537 T-PE1, T-PE2 and S-PE1 when VCCV stitching for CC Type 3 is used. 539 If T-PE1 supports CC Type 4 and S-PE1 supports VCCV stitching for CC 540 Type 4, then VCCV stitching for CC Type 4 is used and both IP-based 541 and ACH-based CV capabilities can be negotiated depending on T-PE1, 542 T-PE2 and S-PE1 CV capabilities. 544 If T-PE1 does not support CC Type 4, it will advertise support only 545 for IP-based CV types and therefore only IP-based CV capabilities 546 can be negotiated depending on T-PE1, T-PE2 and S-PE1 CV 547 capabilities. 549 If S-PE1 does not support VCCV stitching for CC Type 4, it will 550 advertise support only for IP-based CV types and therefore only IP- 551 based CV capabilities can be negotiated depending on T-PE1, T-PE2 552 and S-PE1 CV capabilities. 554 5. Other Deployment Scenarios 556 The solution described in this document is quite generic and can be 557 used in different deployment scenarios, in addition to the reference 558 network outline in Figure 1, without requiring any change to the 559 behavior of the S-PE, as defined in this document. 561 A possible deployment scenario is shows in Figure 3 where both T-PEs 562 are not capable to insert the CW: 564 Original SS-PW 565 (w/o CW) 566 | 567 +-------+ /--------|----------------\ +-------+ 568 | | / V \ | | 569 | T-PE1 +ooooooooooooooooooooooooooooooooooooooooo+ T-PE2 | 570 | | | | | | 571 +---+---+ | | +---+---+ 572 n | | n 573 n<-----+ | MPLS N/W | n<-----+ 574 n | | with ECMP | n | 575 n | | | n | 576 +---+---+ | | | +---+---+ | 577 | | | | | | | | 578 | S-PE1 +ccccccccccccccccccccccccccccccccccccccccc+ S-PE2 | | 579 | | | \ ^ / | | | 580 +-------+ | -------------|----------- +-------+ | 581 | | | 582 | | | 583 | | | 584 PW Segment PW Segment PW Segment 585 (w/o CW) over with CW (w/o CW) over 586 LSP w/o ECMP LSP w/o ECMP 588 Figure 3 Reference network with two T-PEs not capable to insert 589 CW 591 In this scenario, two S-PEs needs to be deployed: S-PE1 in front of 592 T-PE1 and S-PE2 in front of T-PE2. 594 S-PE1 and S-PE2 operate as defined in this document: these 595 operations are the same even if one or both the PW segments switched 596 by one S-PE are terminated at a T-PE or at another S-PE. 598 An even more generic deployment scenario is shows in Figure 3: 600 T-PE1 S-PE1 S-PE2 S-PE3 S-PE4 T-PE2 601 +---+ +---+ +---+ +---+ +---+ +---+ 602 | | | | | | | | | | | | 603 | +nnnnnn+ +nnnnnn+ +cccccc+ +cccccc+ +nnnnnn+ | 604 | | ^ | | | | ^ | | | | | | 605 +---+ | +---+ +---+ | +---+ +---+ +---+ 606 | | 607 | | 608 PW Seg't PW Seg't 609 (no CW) over with CW over 610 LSP no ECMP LSP with or 611 without ECMP 613 Figure 4 More generic Reference network 615 In this case a MS-PW can be setup with some PW segments using the CW 616 and other not using the CW. 618 S-PE1 and S-PE3 operates as defined in [RFC 6073] while S-PE2 and S- 619 PE4 operate as defined in this document: these operations are the 620 same even if one or both the PW segments switched by one S-PE are 621 terminated at a T-PE or at another S-PE operating as defined in [RFC 622 6073] or at another S-PE operating as defined in this document. 624 The operations are also the same if the PW segment not using the CW 625 is setup over a link or over an MPLS network. 627 In order to achieve the desired behavior, i.e., to avoid the issues 628 described in [I-D ETH-CW], care must be taken by the operator to 629 make sure that no ECMP is used within the MPLS network carrying the 630 PW segments without the CW. 632 The operations described in this document work also if static 633 configuration is used instead of T-LDP to setup some or all the PW 634 segments. 636 The operations described in this document work also if dynamic MS-PW 637 signaling procedures, as defined in [RFC7267], are used instead of 638 static configuration of the S-PEs. 640 6. Security Considerations 642 The method described in this document adds no security issues beyond 643 those encountered in a network running multi-segment Ethernet 644 pseudowires with the Control Word over MPLS, as previously discussed 645 in [RFC4385], [RFC4448] and [RFC7267]. Such networks are normally 646 private, well managed, highly controlled environments. 648 7. IANA Considerations 650 This document makes no IANA requests. 652 8. References 654 8.1. Normative References 656 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 657 Requirement Levels", BCP 14, RFC 2119, March 1997. 659 [RFC4385] Bryant, S. et al., "Pseudowire Emulation Edge-to-Edge 660 (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, 661 February 2006. 663 [RFC4447] Martini, L. et al., "Pseudowire Setup and Maintenance 664 Using the Label Distribution Protocol (LDP)", RFC 4447, 665 April 2006. 667 [RFC4448] Martini, L. et al., "Encapsulation Methods for Transport 668 of Ethernet over MPLS Networks", RFC 4448, April 2006. 670 [RFC5085] Nadeu, T., Pignataro, C., " Pseudowire Virtual Circuit 671 Connectivity Verification (VCCV): A Control Channel for 672 Pseudowires", RFC 5085, December 2007. 674 [RFC6073] Martini, L. et al., "Segmented Pseudowire", RFC 6073, 675 January 2011. 677 [RFC7267] Martini, L. et al., "Dynamic Placement of Multi-Segment 678 Pseudowires", RFC 7267, June 2014. 680 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 681 2119 Key Words", BCP 14, RFC 8174, May 2017. 683 [I-D ETH-CW] Bryant, S. et al., "Use of Ethernet Control Word 684 RECOMMENDED", draft-ietf-pals-ethernet-cw, work in 685 progress. 687 8.2. Informative References 689 [RFC6718] Muley, P. et al., "Pseudowire Redundancy", RFC 6718, 690 August 2012. 692 [RFC7771] Malis, A. et al., "Switching Provider Edge (S-PE) 693 Protection for MPLS and MPLS Transport Switching Provider 694 Edge (S-PE) Protection for MPLS and MPLS Transport", RFC 695 7771, January 2016. 697 9. Acknowledgments 699 This document was prepared using 2-Word-v2.0.template.dot. 701 Authors' Addresses 703 Italo Busi 704 Huawei 706 Email: italo.busi@huawei.com 708 Stewart Bryant 709 Huawei 711 Email: stewart.bryant@gmail.com 713 Andrew G. Malis 714 Huawei 716 Email: agmalis@gmail.com 718 Jie Dong 719 Huawei 721 Email: jie.dong@huawei.com