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]
