Internet DRAFT - draft-busi-pals-pw-cw-stitching

draft-busi-pals-pw-cw-stitching



PALS Working Group                                           Italo Busi
Internet Draft                                           Stewart Bryant
Intended status: Standard Track                         Andrew G. Malis
Expires: April 2019                                            Jie Dong
                                                                 Huawei

                                                       October 22, 2018



                Pseudowire (PW) Control Word (CW) Stitching
                  draft-busi-pals-pw-cw-stitching-01.txt


Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on April 22, 2019.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document. Code Components extracted from this



Busi, al.               Expires April 22, 2019                 [Page 1]

Internet-Draft             PW CW Stitching                 October 2018


   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.

Abstract

   This document defines the behavior of a new type of Multi-Segment
   Pseudowire (MS-PW) Switching PE (S-PE) which enhances the S-PE
   functions defined in [RFC 6073], with the capability to switch an
   Ethernet pseudowire (PW) segment that uses the PW Control Word (CW)
   [RFC 4385] with an Ethernet PW segment that does not use the CW.

   This new type of S-PE can be deployed in the network one hop away,
   at the MPLS layer, from a Terminating PE (T-PE) which does not
   support CW for Ethernet PW encapsulation [RFC 4448]. In this way,
   all the Ethernet PW packets sent though the MPLS network will have
   the CW and be protected against incorrect equal-cost-multi-path
   (ECMP) behavior as described in [I-D ETH-CW].

Table of Contents


   1. Introduction...................................................2
      1.1. Assumptions...............................................5
   2. Terminology....................................................5
      2.1. Conventions Used in This Document.........................6
   3. Control Word Stitching procedures..............................6
      3.1. CW Stitching Signaling....................................7
   4. VCCV Stitching Procedures......................................8
      4.1. VCCV Stitching for CC Type 3..............................9
      4.2. VCCV Stitching for CC Type 4.............................10
      4.3. VCCV Stitching Signaling.................................12
   5. Other Deployment Scenarios....................................13
   6. Security Considerations.......................................15
   7. IANA Considerations...........................................16
   8. References....................................................16
      8.1. Normative References.....................................16
      8.2. Informative References...................................16
   9. Acknowledgments...............................................17

1. Introduction

   In order to protect Ethernet pseudowire (PW) packets against
   incorrect equal-cost-multi-path (ECMP) behavior, which may cause
   out-of-order delivery of the payload Ethernet frames, the use of PW
   control word (CW) has been recommended in [I-D ETH-CW].



Busi, al.               Expires April 22, 2019                 [Page 2]

Internet-Draft             PW CW Stitching                 October 2018


   There are cases where service providers have existing deployments
   where the Provider Edge (PE) device is an old piece of equipment
   which does not support the CW for Ethernet PW encapsulation. In this
   case, the CW shall not be used as defined in [RFC 4448].

   There are situations where replacing this PE with a new piece of
   equipment which supports CW for Ethernet PW is not acceptable
   because of economical or operational (e.g., service disruption time)
   reasons.

   It may be beneficial to give operators an option to deploy (or re-
   use) another piece of equipment, located one hop away at the MPLS
   layer from this PE (typically physically co-located), which can add
   the CW to the Ethernet PW packets received from this PE, before
   sending them though an MPLS network.

   This node should behave as a Switching PE (S-PE) as defined in [RFC
   6073] and also be capable of switching an Ethernet pseudowire (PW)
   segment that uses the control word (CW) with an Ethernet PW segment
   that does not use the CW.

   The reference network is shown in Figure 1 below.



























Busi, al.               Expires April 22, 2019                 [Page 3]

Internet-Draft             PW CW Stitching                 October 2018


                          Original SS-PW
                             (w/o CW)
                                |
       +-------+       /--------|----------------\       +-------+1
       |       |      /         V                 \      |       |
       | T-PE1 +ooooooooooooooooooooooooooooooooooooooooo+ T-PE2 |
       |       |     |                     +ccccccccccccc+       |
       +---+---+     |                     c       |     +-------+
           n         |                     c       |
           n<-----+  |   MPLS N/W          c       |
           n      |  |   with ECMP         c       |
           n      |  |                     c       |
       +---+---+  |  |                     c       |
       |       |  |  |                     c       |
       | S-PE1 +ccccccccccccccccccccccccccc+       /
       |       |  |    \             ^            /
       +-------+  |     -------------|-----------
                  |                  |
                  |                  |
                  |                  |
             PW Segment         PW Segment
           (w/o CW) over        with CW
            LSP w/o ECMP

                         Figure 1 Reference Network

   In Figure 1, T-PE1 is a device which is not capable of including a
   CW in Ethernet PW encapsulation, T-PE2 is a device which is capable
   to use the CW for Ethernet PW encapsulation, while S-PE1 is the new
   type of device defined in this document.

   S-PE1 can be added to the network with minimum or no service
   disruption and PW redundancy [RFC 6718] or [RFC 7771] can be used to
   move the traffic from the old single-segment PW (SS-PW) without the
   CW to the new multi-segment PW (MS-PW) with the CW on the PW segment
   that passes through the MPLS network.

   The deployment of the S-PE1, either as a new router or as an upgrade
   of an existing router, does not require any changes/upgrades to
   other nodes already installed within the network.

   It is expected that in new deployments, all the Provider Edge (PE)
   devices are capable to insert the CW for Ethernet PW encapsulation
   and therefore the solution described in this document mainly applies
   to existing deployments where there are old pieces of equipment not
   being capable to support the CW for Ethernet PW encapsulation.



Busi, al.               Expires April 22, 2019                 [Page 4]

Internet-Draft             PW CW Stitching                 October 2018


1.1. Assumptions

   This document assumes that T-PE1 operates in the same way regardless
   of whether the PW is a SS-PW or a MS-PW, as defined in [RFC 6073]:

   o  T-PE1 signals SS-PW with T-PE2 using T-LDP, as defined in [RFC
      4447]

   o  T-PE1 could be configured to signal a PW segment with S-PE1, as
      if it were T-PE2 using T-LDP, following the procedures defined in
      [RFC 6073].

   o  T-PE1 is capable to set the PW-TTL value (i.e., the TTL value of
      the PW LSE) for Ethernet PW packets to a proper value that allows
      the Ethernet frames to be forwarded on the AC on T-PE2 (e.g., PW-
      TTL>2 in Figure 1): this could be done either via administrative
      configuration or though T-LDP information.

   It is also assumed that if T-PE1 supports Pseudowire Virtual Circuit
   Connectivity Verification (VCCV), it can support at least CC Type 3
   or CC Type 4. The underlying rationale for this assumption is that
   use of CC Type 2 for MS-PW is not allowed in [RFC 6073].

   If T-PE1 supports CC Type 3, it is assumed that it is capable to set
   the PW-TTL value for the VCCV packets to a proper value that allows
   the VCCV packets to be recognized by T-PE2 by PW-TTL expiry (e.g.,
   PW-TTL=2): this could be done either via administrative
   configuration or though T-LDP information.

   It is assumed that S-PE1 is manually configured to switch between
   the two PW segments, following the procedure described in [RFC
   6073].

   If T-PE2 supports VCCV, it is configured to always advertise support
   for CC type 1. This would allow simplifying the VCCV switching
   process since CC type 1 is always used on the PW segment with CW.

2. Terminology

   This document re-uses the terminology defined in [RFC 6073] for
   single-segment pseudo-wire (SS-PW), multi-segment PW (MS-PW),
   terminating provider edge (T-PE) and switching provider edge (S-PE).

   This document uses the acronym PW-TTL to indicate the TTL value in
   the PW label stack entry (LSE).




Busi, al.               Expires April 22, 2019                 [Page 5]

Internet-Draft             PW CW Stitching                 October 2018


2.1. Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3. Control Word Stitching procedures

   The CW stitching procedure is performed by the S-PE1 on the Ethernet
   PW packets it is forwarding.

   With a reference to Figure 1, it performs the following operations,
   in the direction from T-PE1 to T-PE2:

   1. It pops the MPLS label stack entry (LSE) of the LSP from T-PE1 to
      S-PE1, if not PHP-ed by the penultimate LSR

   2. It swaps the PW label (and decrements the PW-TTL)

   3. It adds the CW immediately following the bottom of the label
      stack

   4. It pushes the MPLS LSE for the LSP to T-PE2, unless this LSP is a
      single-hop PHP-ed LSP.

   It is worth noting that step 3 is the only addition to the S-PE
   forwarding rules defined in [RFC 6073].

   In this step, the S-PE inserts also the sequence number field in the
   control word, following the rules defined in [RFC4448].

   In the opposite direction, S-PE1 performs the following operations:

   1. It pops the MPLS label stack entry (LSE) for the LSP from T-PE2
      to S-PE1, if not PHP-ed by the penultimate LSR

   2. It swaps the PW label (and decrements the PW-TTL)

   3. It removes the CW, which is located immediately following the
      bottom of the label stack

   4. It pushes the MPLS LSE for the LSP to T-PE2, unless this LSP is a
      single-hop PHP-ed LSP.




Busi, al.               Expires April 22, 2019                 [Page 6]

Internet-Draft             PW CW Stitching                 October 2018


   It is worth noting that step 3 is the only addition to the S-PE
   forwarding rules defined in [RFC 6073].

   In this step, the S-PE MAY also process the sequence number field in
   the control word, following the rules defined in [RFC4448].

3.1. CW Stitching Signaling

   S-PE1 negotiates CW capabilities with T-PE1 and T-PE2 following
   almost the same procedures defined in [RFC 4447] and [RFC 6073].

   The only exception to the procedures defined in [RFC 6073] is that
   S-PE1, when signaling one PW segment, will always behave as if the
   CW is supported on the other PW segment.

   This allows S-PE1 to negotiate different CW capabilities on
   different PW segments as well as to enable CW toward any T-PE that
   support CW insertion.

   If the same CW capabilities are negotiated on both PW segments, then
   S-PE1 will behave as specified in [RFC 6073]. CW stitching, as
   defined in this document, is enabled if and only if different CW
   capabilities are negotiated on the two PW segments.

   In case the S-PE considers the sequence number field in the control
   word, it SHALL follow the rules described in section 6.4 of
   [RFC4447].

                  PW Seg't            PW Seg't
                  (no CW)             (with CW)
                     |                   |
       +-------+     |     +-------+     |     +-------+
       |       |==== V ====|       |==== V ====|       |
       | T-PE1 +-----------+ S-PE1 +-----------+ T-PE2 |
       |       |===========|       |===========|       |
       +-------+    LSP1   +-------+    LSP2   +-------+

                    C=0                  C=1
                ----------->         ---------->

                [C=1 ->] C=0             C=1
                <-----------         <----------

                       Figure 2 CW Stitching Signaling

   Figure 2 shows an example of how CW capabilities are negotiated in
   the reference network scenario of Figure 1.


Busi, al.               Expires April 22, 2019                 [Page 7]

Internet-Draft             PW CW Stitching                 October 2018


   T-PE1 will send a T-LDP Label Mapping message with c=0 and T-PE2
   will send a T-LDP Label Mapping message with C=1, following the
   procedures defined in section 6.2 of [RFC 4447] and amended by [I-D
   ETH-CW].

   After S-PE1 receives the T-LDP Label Mapping message (with c=1) from
   T-PE2, it can send a T-LDP Label Mapping message back to T-PE2 (with
   c=1), following the procedures defined in section 6.2 of [RFC 4447],
   and a T-LDP Label Mapping messages to T-PE1 (with c=1), following
   the procedures of [RFC 6073].

   After S-PE1 receives the T-LDP Label Mapping message (with c=0) from
   T-PE1, it can send a T-LDP Label Mapping message to T-PE2 (with
   c=1), as if it has received c=1 from T-PE1. It can also send a T-LDP
   Label Mapping message back to T-PE1 with c=0, following the
   procedures defined in section 6.2 of [RFC 4447].

   If S-PE1 receives the T-LDP Label Mapping message (with c=0) from T-
   PE1 after having sent a T-LDP Label Mapping message with c=1 to T-
   PE1, a Label Withdraw message needs to be sent to T-PE1 before
   sending another Label Mapping message with c=1, as specified in
   section 6.2 of [RFC 4447].

   When the MS-PW is completely setup:

   o  T-PE1 is configured not to insert CW

   o  T-PE2 is configures to insert CW

   o  S-PE1 is configured to stitch the CW between the two PW segments

4. VCCV Stitching Procedures

   When CW stitching is enabled, VCCV packets sent on the two PW
   segments would have different formats. In order to enable end-to-end
   OAM, S-PE1 needs to be capable to perform VCCV stitching.

   Since support of CC Type 1 is REQUIRED by [RFC 5085] for PWs that
   support the CW, within this document it is RECOMMENDED that its use
   is always enabled at the T-PEs supporting the CW (e.g., T-PE2) such
   that, following the rules defined in [RFC 5085], when VCCV is in
   use, CC Type 1 is always used on the PW segment that support the CW.

   Since [RFC 5085] does not define any mandatory CC Types for the PWs
   that do not support CW, different VCCV stitching procedures need to
   be defined depending on the CC Type supported by the T-PE not
   supporting the CW (e.g., T-PE1).


Busi, al.               Expires April 22, 2019                 [Page 8]

Internet-Draft             PW CW Stitching                 October 2018


   The VCCV stitching procedure is performed by S-PE1 on the VCCV
   packets it is forwarding.

   In the traffic direction from T-PE2 and T-PE1 CC Type 1 is used: S-
   PE1 can distinguish VCCV and Ethernet PW packets by looking at the
   first nibble immediately following the bottom of the label stack
   which identifies either an ACH or a CW:

   o  Ethernet PW packets are received with the CW: these packets need
      to be forwarded following the rules defined in section 3.

   o  VCCV packets targeted at S-PE1 are received with the ACH and the
      PW-TTL=1: these packets should be processed by S-PE1 and not
      forwarded.

   o  Other VCCV packets are received with the ACH and with a PW-TTL
      value greater than 1: these packets need to be forwarded
      following the rules defined in the following sections.

   In the traffic direction from T-PE1 and T-PE2, the rules used to
   distinguish VCCV packets from Ethernet PW packets depends from the
   CC Type used on the PW segment without the CW.

4.1. VCCV Stitching for CC Type 3

   In case CC Type 3 is used on the PW segment not using the CW, VCCV
   stitching needs to translate between CC Type 3 (without the CW) and
   CC Type 1. It is worth noting that when CC Type 3 is used on PW
   segments not using the CW, only IP-based CV types can be supported.

   In the traffic direction from T-PE1 and T-PE2, S-PE1 can distinguish
   VCCV and Ethernet PW packets by looking at the PW-TTL value:

   o  Ethernet PW packets are received with a PW-TTL value exceeding
      the PW-TTL distance from S-PE1 to T-PE2 (e.g., TTL>2): these
      packets need to be forwarded following the rules defined in
      section 3.

   o  VCCV packets targeted at S-PE1 are received with PW-TTL=1: these
      packets should be processed by S-PE1 and not forwarded.

   o  Other VCCV packets are received with a PW-TTL value greater than
      1 and not exceeding the PW-TTL distance to T-PE2 (e.g., TTL=2):
      these packets need to be forwarded following the rules defined in
      this section.




Busi, al.               Expires April 22, 2019                 [Page 9]

Internet-Draft             PW CW Stitching                 October 2018


   With a reference to Figure 1, S-PE1 performs the following
   operations, in the direction from T-PE1 to T-PE2:

   1. It pops the MPLS label stack entry (LSE) of the LSP from T-PE1 to
      S-PE1, if not PHP-ed by the penultimate LSR

   2. It swaps the PW label (and decrements the PW-TTL)

   3. It adds the ACH immediately following the bottom of the label
      stack (setting the ACH Channel Type based on the IP version field
      of the encapsulated IP packet)

   4. It pushes the MPLS LSE for the LSP to T-PE2, unless this LSP is a
      single-hop PHP-ed LSP.

   It is worth noting that step 3 is the only addition to the S-PE
   forwarding rules defined in [RFC 6073]: it is also the only step
   where the forwarding rules of VCCV packets are different from the
   forwarding rules defined for Ethernet PW packets in section 3.

   S-PE1 can understand the IP version field of the encapsulated IP
   packet by looking at the first nibble immediately following the
   bottom of the label stack of the received packet.

   In the opposite direction, S-PE1 performs the following operations:

   1. It pops the MPLS label stack entry (LSE) for the LSP from T-PE2
      to S-PE1, if not PHP-ed by the penultimate LSR

   2. It swaps the PW label (and decrements the PW-TTL)

   3. It removes the ACH, which is located immediately following the
      bottom of the label stack

   4. It pushes the MPLS LSE for the LSP to T-PE2, unless this LSP is a
      single-hop PHP-ed LSP.

   It is worth noting that step 3 is the only addition to the S-PE
   forwarding rules defined in [RFC 6073]: it is also the only step
   where the forwarding rules of VCCV packets are different from the
   forwarding rules defined for Ethernet PW packets in section 3.

4.2. VCCV Stitching for CC Type 4

   In case CC Type 4 is used on the PW segment not using the CW, VCCV
   stitching needs to translate between CC Type 4 and CC Type 1. It is



Busi, al.               Expires April 22, 2019                [Page 10]

Internet-Draft             PW CW Stitching                 October 2018


   worth noting that in this case both IP-based and ACH-based CV types
   can be supported.

   In the traffic direction from T-PE1 and T-PE2, S-PE1 can distinguish
   VCCV and Ethernet PW packets by looking at GAL LSE right after the
   PW LSE:

   o  Ethernet PW packets are received without a GAL LSE: these packets
      need to be forwarded following the rules defined in section 3.

   o  VCCV packets targeted at S-PE1 are received with the GAL LSE and
      with the PW-TTL=1: these packets should be processed by S-PE1 and
      not forwarded.

   o  Other VCCV packets are received with the GAL LSE and with a PW-
      TTL value greater than 1: these packets need to be forwarded
      following the rules defined in this section.

   With a reference to Figure 1, S-PE1 performs the following
   operations, in the direction from T-PE1 to T-PE2:

   1. It pops the MPLS label stack entry (LSE) of the LSP from T-PE1 to
      S-PE1, if not PHP-ed by the penultimate LSR

   2. It swaps the PW label (and decrements the PW-TTL)

   3. It removes the GAL LSE at the bottom of the label stack

   4. It sets the S-bit of the PW LSE since the PW LSE becomes the new
      bottom of the label stack

   5. It pushes the MPLS LSE for the LSP to T-PE2, unless this LSP is a
      single-hop PHP-ed LSP.

   It is worth noting that steps 3 and 4 are the only additions to the
   S-PE forwarding rules defined in [RFC 6073]: they are also the only
   steps where the forwarding rules of VCCV packets are different from
   the forwarding rules defined for Ethernet PW packets in section 3.

   In the opposite direction, S-PE1 performs the following operations:

   1. It pops the MPLS label stack entry (LSE) for the LSP from T-PE2
      to S-PE1, if not PHP-ed by the penultimate LSR

   2. It swaps the PW label (and decrements the PW-TTL)

   3. It inserts the GAL LSE at the bottom of the label stack


Busi, al.               Expires April 22, 2019                [Page 11]

Internet-Draft             PW CW Stitching                 October 2018


   4. It clears the S-bit of the PW LSE since the PW LSE is no longer
      at the bottom of the label stack

   5. It pushes the MPLS LSE for the LSP to T-PE2, unless this LSP is a
      single-hop PHP-ed LSP.

   It is worth noting that steps 3 and 4 are the only additions to the
   S-PE forwarding rules defined in [RFC 6073]: they are also the only
   steps where the forwarding rules of VCCV packets are different from
   the forwarding rules defined for Ethernet PW packets in section 3.

4.3. VCCV Stitching Signaling

   S-PE1 negotiates VCCV capabilities with T-PE1 and T-PE2 following
   almost the same procedures defined in [RFC 5085] and [RFC 6073].

   If the same CW capabilities are negotiated on both PW segments, then
   S-PE1 will behave as specified in [RFC 6073]. VCCV stitching, as
   defined in this document, is enabled if and only if different CW
   capabilities are negotiated on the two PW segments.

   If S-PE1 supports VCCV stitching for CC Type 3, and it knows the PW-
   TTL distance to both T-PE1 and T-PE2:

   o  If T-PE1 advertises support for CC Type 3, S-PE1 advertises
      support for CC Type 1 to T-PE2

   o  If T-PE2 advertises support for CC Type 1, S-PE1 behaves toward
      T-PE1 if it supports CC Type 3 and T-PE2 has advertised support
      for CC Type 3, following the procedure defined in [RFC 6073]

   If S-PE1 supports VCCV stitching for CC Type 4:

   o  If T-PE1 advertises support for CC Type 4, S-PE1 advertises
      support for CC Type 1 to T-PE2

   o  If T-PE2 advertises support for CC Type 1, S-PE1 behaves toward
      T-PE1 as if it supports CC Type 4 and T-PE2 has advertised
      support for CC Type 4, following the procedure defined in [RFC
      6073]

   CV types are advertised based on S-PE1 capabilities as per [RFC
   6073] with the following additional rule:

   o  S-PE1 can advertise support for ACH-based CV types if and only if
      it supports VCCV stitching for CC Type 4



Busi, al.               Expires April 22, 2019                [Page 12]

Internet-Draft             PW CW Stitching                 October 2018


   This rule ensures that only IP-based CV types are negotiated between
   T-PE1, T-PE2 and S-PE1 when VCCV stitching for CC Type 3 is used.

   If T-PE1 supports CC Type 4 and S-PE1 supports VCCV stitching for CC
   Type 4, then VCCV stitching for CC Type 4 is used and both IP-based
   and ACH-based CV capabilities can be negotiated depending on T-PE1,
   T-PE2 and S-PE1 CV capabilities.

   If T-PE1 does not support CC Type 4, it will advertise support only
   for IP-based CV types and therefore only IP-based CV capabilities
   can be negotiated depending on T-PE1, T-PE2 and S-PE1 CV
   capabilities.

   If S-PE1 does not support VCCV stitching for CC Type 4, it will
   advertise support only for IP-based CV types and therefore only IP-
   based CV capabilities can be negotiated depending on T-PE1, T-PE2
   and S-PE1 CV capabilities.

5. Other Deployment Scenarios

   The solution described in this document is quite generic and can be
   used in different deployment scenarios, in addition to the reference
   network outline in Figure 1, without requiring any change to the
   behavior of the S-PE, as defined in this document.

   A possible deployment scenario is shows in Figure 3 where both T-PEs
   are not capable to insert the CW:






















Busi, al.               Expires April 22, 2019                [Page 13]

Internet-Draft             PW CW Stitching                 October 2018


                      Original SS-PW
                         (w/o CW)
                            |
   +-------+       /--------|----------------\       +-------+
   |       |      /         V                 \      |       |
   | T-PE1 +ooooooooooooooooooooooooooooooooooooooooo+ T-PE2 |
   |       |     |                             |     |       |
   +---+---+     |                             |     +---+---+
       n         |                             |         n
       n<-----+  |   MPLS N/W                  |         n<-----+
       n      |  |   with ECMP                 |         n      |
       n      |  |                             |         n      |
   +---+---+  |  |                             |     +---+---+  |
   |       |  |  |                             |     |       |  |
   | S-PE1 +ccccccccccccccccccccccccccccccccccccccccc+ S-PE2 |  |
   |       |  |    \             ^            /      |       |  |
   +-------+  |     -------------|-----------        +-------+  |
              |                  |                              |
              |                  |                              |
              |                  |                              |
        PW Segment         PW Segment                     PW Segment
       (w/o CW) over        with CW                      (w/o CW) over
        LSP w/o ECMP                                      LSP w/o ECMP

       Figure 3 Reference network with two T-PEs not capable to insert
                                       CW

   In this scenario, two S-PEs needs to be deployed: S-PE1 in front of
   T-PE1 and S-PE2 in front of T-PE2.

   S-PE1 and S-PE2 operate as defined in this document: these
   operations are the same even if one or both the PW segments switched
   by one S-PE are terminated at a T-PE or at another S-PE.

   An even more generic deployment scenario is shows in Figure 3:














Busi, al.               Expires April 22, 2019                [Page 14]

Internet-Draft             PW CW Stitching                 October 2018


       T-PE1      S-PE1      S-PE2      S-PE3      S-PE4      T-PE2
       +---+      +---+      +---+      +---+      +---+      +---+
       |   |      |   |      |   |      |   |      |   |      |   |
       |   +nnnnnn+   +nnnnnn+   +cccccc+   +cccccc+   +nnnnnn+   |
       |   |  ^   |   |      |   |  ^   |   |      |   |      |   |
       +---+  |   +---+      +---+  |   +---+      +---+      +---+
              |                     |
              |                     |
           PW Seg't               PW Seg't
         (no CW) over             with CW over
          LSP no ECMP             LSP with or
                                  without ECMP

                   Figure 4 More generic Reference network

   In this case a MS-PW can be setup with some PW segments using the CW
   and other not using the CW.

   S-PE1 and S-PE3 operates as defined in [RFC 6073] while S-PE2 and S-
   PE4 operate as defined in this document: these operations are the
   same even if one or both the PW segments switched by one S-PE are
   terminated at a T-PE or at another S-PE operating as defined in [RFC
   6073] or at another S-PE operating as defined in this document.

   The operations are also the same if the PW segment not using the CW
   is setup over a link or over an MPLS network.

   In order to achieve the desired behavior, i.e., to avoid the issues
   described in [I-D ETH-CW], care must be taken by the operator to
   make sure that no ECMP is used within the MPLS network carrying the
   PW segments without the CW.

   The operations described in this document work also if static
   configuration is used instead of T-LDP to setup some or all the PW
   segments.

   The operations described in this document work also if dynamic MS-PW
   signaling procedures, as defined in [RFC7267], are used instead of
   static configuration of the S-PEs.

6. Security Considerations

   The method described in this document adds no security issues beyond
   those encountered in a network running multi-segment Ethernet
   pseudowires with the Control Word over MPLS, as previously discussed
   in [RFC4385], [RFC4448] and [RFC7267]. Such networks are normally
   private, well managed, highly controlled environments.


Busi, al.               Expires April 22, 2019                [Page 15]

Internet-Draft             PW CW Stitching                 October 2018


7. IANA Considerations

   This document makes no IANA requests.

8. References

8.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4385] Bryant, S. et al., "Pseudowire Emulation Edge-to-Edge
             (PWE3) Control Word for Use over an MPLS PSN", RFC 4385,
             February 2006.

   [RFC4447] Martini, L. et al., "Pseudowire Setup and Maintenance
             Using the Label Distribution Protocol (LDP)", RFC 4447,
             April 2006.

   [RFC4448] Martini, L. et al., "Encapsulation Methods for Transport
             of Ethernet over MPLS Networks", RFC 4448, April 2006.

   [RFC5085] Nadeu, T., Pignataro, C., " Pseudowire Virtual Circuit
             Connectivity Verification (VCCV): A Control Channel for
             Pseudowires", RFC 5085, December 2007.

   [RFC6073] Martini, L. et al., "Segmented Pseudowire", RFC 6073,
             January 2011.

   [RFC7267] Martini, L. et al., "Dynamic Placement of Multi-Segment
             Pseudowires", RFC 7267, June 2014.

   [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
             2119 Key Words", BCP 14, RFC 8174, May 2017.

   [I-D ETH-CW]   Bryant, S. et al., "Use of Ethernet Control Word
             RECOMMENDED", draft-ietf-pals-ethernet-cw, work in
             progress.

8.2. Informative References

   [RFC6718] Muley, P. et al., "Pseudowire Redundancy", RFC 6718,
             August 2012.






Busi, al.               Expires April 22, 2019                [Page 16]

Internet-Draft             PW CW Stitching                 October 2018


   [RFC7771] Malis, A. et al., "Switching Provider Edge (S-PE)
             Protection for MPLS and MPLS Transport Switching Provider
             Edge (S-PE) Protection for MPLS and MPLS Transport", RFC
             7771, January 2016.

9. Acknowledgments

   This document was prepared using 2-Word-v2.0.template.dot.









































Busi, al.               Expires April 22, 2019                [Page 17]

Internet-Draft             PW CW Stitching                 October 2018


Authors' Addresses

   Italo Busi
   Huawei

   Email: italo.busi@huawei.com


   Stewart Bryant
   Huawei

   Email: stewart.bryant@gmail.com


   Andrew G. Malis
   Huawei

   Email: agmalis@gmail.com


   Jie Dong
   Huawei

   Email: jie.dong@huawei.com

























Busi, al.               Expires April 22, 2019                [Page 18]