Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01

From: Stewart Bryant <[email-masked]>
Date: Tue, 05 Aug 2014 11:56:27 +0100

On 30/07/2014 20:07, Yimin Shen wrote:
> Hi Stewart,
>
> Thanks very much for the detailed review and comments. I'd like to highlight a few things below about this draft, and then respond to your comments inline. Hope you could give the draft another closer look.
Yimin,

Having read your reply and having looked at the text again,
and talked to a few folks I think I now understand the top
level view of what is proposed. However that is in itself
an indication that the draft needs considerable work
before publication. Note that it was not initially obvious
that you supported both LDP and RSVP-TE PSNs, nor
was it initially obvious that you were using the PSN to
protect the PWs and not looking further down the stack.
Indeed I think there is some text in the draft that positively
leads you in that direction since someone else picked
it it during an MPLS review.

To summarize: what you are doing is construct  repairs
at the PSN layer that map to each combination of PW + PW repair,
which I think multiples the number of PSN tunnels by three times
the dispersion factor where the dispersion factor is some factor
defining the average number of PEs that the PWs addressed to
a single PE need to be dispersed to.

This leads to two questions that the WG needs to think about:

1) This is trading increased PSN state for response time.
Given that PSN state was a critical factor in the choice of the Martini
design over the CCC design this needs to be made clear up front
in the text and the WG needs to decide that this is acceptable.

2) This increased state and the complexity of introducing
context labels and protection routers to the PWE3 architecture
is directly traceable to the need to do xPE node protection,
and is not required for link protection including the egress AC.

This desire to build the design around node protection (which
always adds significant complexity to FRR) is in contrast to
the IPFRR situation where link protection is of overwhelming
importance and node protection seems to be of secondary
importance.

An alternative design, which would require less change to the
existing PWE3 design would be to provide redundant connection
to the xPEs and allow FRR link protection in the PSN to
deal with link failures and then to protect the egress AC by
making the T-PE a special type of S-PE that preferred to
act as a T-PE but if the AC was down forwarded to an alternate
T-PE for that PW.

If the WG prefers to introduce the cross layer scheme you have
proposed, then fine, we need to do the full set of updates needed.
However first I think that we need to have rough consensus that
the use cases and requirements justify the increased complexity
compared of node protection compared to the alternative of
providing link and AC protection.
>
> [1] This draft is completely based on the PWE3 and the MS-PW architecture. It is also based on RFC 5331 " MPLS Upstream Label Assignment and Context-Specific Label Space". So ideally readers should be familiar with that RFC.
As far as I can see context labels have not been introduced
into the PWE3 architecture. There is some reference to their use for
P2MP PWs, but not in the P2P case. Indeed I think that RFC4447
notes explicitly that in the case where the configuration of PWs
is signaled by LDP the platform label space must be used. The
least that you need to do is to update RFC4447.

Something that I noticed in a second pass through the text is that
you seem to have changed the PW FEC data structure from the
one specified by PWE3 to a variant of one used in LSP Ping. This
seems unnecessary and may lead to confusion and difficulty if
these get changed at some time in the future. A better design
is surely to leave the PWE3 signalling system completely unchanged
except to add an additional TLV specifying the context information
if indeed we continue on that path. Apropos this, it may be the
way that the document was written, but I did not see anything about
the need to signal the PW interface parameters to the alternative
PE. Also I did not see anything specifying the error handling
as a result of parameter issues.

A comment below that was not picked up is that the signalling
design supports IPv4 only, and as I recall there is an IESG policy
of not standardizing any IPv4 only solutions, so perhaps we should
introduce IPv6 at the same time as harmonizing the normal and
context label data structures.

The LDP signalling of PWs with context labels need a more
complete review for both completeness and correctness and
to ensure that this text provides a description that is sufficiently
complete that this new feature can be implemented solely from
this text and the associated references.
>
> [2] The draft mentions two important roles of routers, PLR (point of local repair) and protector.
You need a clearer definition of a PLR and protector. I think that
a protector is a new type of SPE and needs a clearer architectural
definition.

The concept of a PLR taking action at one layer within the context
of another is new in PWE3. Perhaps it is defined in MPLS in which
case a reference would be appropriate.
>
> [3] PLR performs local repair in dataplane, based on pre-installed backup forwarding state pointing to a bypass tunnel. There is no control-plane involvement in local repair.
Specifically in the initiation of the local repair, it is in the 
configuration
of course.
> This is similar to the existing IP/MPLS fast-reroute mechanisms. Therefore, it can achieve restore traffic with a similar performance to those mechanisms. That is the main goal of this draft.
IP/MPLS FRR normally operates solely for the benefit of its own
dataplane. You have this configured to act for the benefit of the
client dataplane.
>
> [4] When doing local repair, the PLR only swaps the top label (i.e. tunnel label) to a bypass tunnel's label, and keeps the PW label (allocated by primary/protected PE) intact. The PLR doesn't need to know or understand the PW label.
Indeed this is clearer now, and needs to be made much clearer in
the text.

However so do the implications for the system as a whole of this
mode of operation.
>
> [5] The protector is the router at the other end of the bypass tunnel. It is responsible for forwarding the traffic further, so that the traffic can eventually reach the target CE. The protector must understand the PW label allocated by the primary PE.
The use of the work primary PE is slightly confusing. Presumably
you mean the ingress PE of the segment rather than the ingress
PE from the point of view of the ingress AC.
> This is achieved by using the context label forwarding paradigm specified in RFC 5331. This draft defines some LDP extensions to allow the primary PE to advertise PW labels to the protector. The protector locally maintains a label space for these PW labels of the protected PE, and looks up the PW label in this label space. The bypass tunnel serves as the pointer to this label space.
Now I understand that. Please make this much clearer
earlier in the text.

Note my earlier concern about the design of those extensions.
>
> [6] This draft also introduces the concept of "context ID". A context ID is an IP address identifying a pair of <primary PE, protector X>.
The use of an IP address rather than some identifier taken from
the PW context is a design assumption not properly shared with the
reader and needs to be clarified in the text.

> It serves as the destination of transport tunnel. PWs carried by the tunnel will be redirected to the protector X during local repair. PWs to the same primary PE but protected by a different protector Y cannot be carried by this tunnel. Rather, they must be carried by a tunnel destined for context ID of <primary PE, protector Y>.
Indeed, but that needs to be made clearer, particularly as this
seemingly has scaling consequences.
>
> [7] A PLR may be any router in the network, including P or PE router. The draft assumes that it doesn't know or care about PW info.
>
> [8] A protector is a PE router
Within a PE context I am not sure that the properties of a PE router
are defined.
> in the "co-located" model. It may be a P router in the "centralized" model. For the later case, the draft describes how to use the new LDP extensions for the protector to learn and assoicate primary PW and backup PW and install forwarding entries in the context label table.
So when you run the centralized protector, how does the
PW parameter signaling and interface parameter verification
work? Surely the centralized protector needs to be some
form of PE rather than a variant of an MPLS P router?

I have a bunch of comments on your answer below, put perhaps we
can start by working through the comments above and the cycle
back to the comments below within the resultant context.

I will comment on our exchange below when we have reached
some level of consensus on the preamble.

Given the concerns that I have raised and those raised by Sasha
I think that the chairs need consider taking this back to the WG
for further work.

- Stewart
>
> Thanks,
>
> /Yimin
>
>
> -----Original Message-----
> From: pwe3 [mailto:[email-masked]] On Behalf Of Stewart Bryant
> Sent: Tuesday, July 29, 2014 10:53 AM
> To: pwe3; [email-masked]
> Cc: [email-masked]
> Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01
>
>
>
> I do not support the publication of this draft without:
>
> 1) An assurance that MPLS WG has reviewed it and is happy
> with the extensions that seem to be made to the MPLS architecture
>
> 2) A formal description of those extensions or a pointer
> to those extensions in another RFC.
>
> 3) Significant clarification of how the detail of this
> mechanism works.
>
> For this to work you need to have co-ordinated label spaces
> in multiple PEs which is something that was investigated
> by the SPRING WG and found not to work, particularly when
> different manufacturers equipments were involved.
>
> [yshen] This draft does not rely on label space coordination. Rather, it is based on context label forwarding paradigm specified in RFC 5331.
>
>
> As far as I can see you also need to peek below the top
> of stack to do a fast reroute operation which is not
> a currently defined MPLS operation.
>
> There seem to be a lot of details and clarifications missing
> that need to be provided, and I am not entirely convinced
> that all of the items declared out of scope are legitimately
> out of scope and not needed in order for a multi-vendor
> solution to be implemented.
>
> It would be useful to me (and I suspect to other readers)
> to see what the dataplane looks like at various points
> in the normal and repair path to verify that all parties
> have the right information for this to work under normal
> and various fault conditions.
>
> I have a number of comments inline that need to be addressed
> before this can proceed.
>
>
> - Stewart
>
>
>                     PW Endpoint Fast Failure Protection
>                 draft-ietf-pwe3-endpoint-fast-protection-01
>
> Abstract
>
>      This document specifies a fast mechanism for protecting pseudowires
>      against egress endpoint failures, including egress attachment circuit
>      failure, egress PE failure, multi-segment PW terminating PE failure,
>      and multi-segment PW switching PE failure.  Designed on the basis of
>      multi-homed CE, PW redundancy, upstream label assignment and context
>      specific label switching, the mechanism enables local repair to be
>      performed by the router upstream adjacent to a failure.
>
>      In
>      particular, the router can restore PW traffic in the order of tens of
>      milliseconds,
>
> SB> Not sure it's wise to specify a performance claim in a standards
> SB> track RFC.
>
> [yshen] If this is viewed as inappropriate, we can remove it.
>
>      by transmitting the traffic to a protector through a
>      pre-established bypass tunnel.  Therefore, the mechanism can reduce
>      traffic loss before global repair reacts to the failure and the
>      network converges on the topology changes due to the failure.
>
>
>
> ===
>
>
> 1.  Introduction
>
>      Per RFC 3985, RFC 4447 and RFC 5659, a pseudowire (PW) or PW segment
>      can be thought of as a connection between a pair of forwarders hosted
>      by two PEs, carrying an emulated layer-2 service over a packet
>      switched network (PSN).  In the single-segment PW (SS-PW) case, a
>      forwarder binds a PW to an attachment circuit (AC).  In the multi-
>      segment PW (MS-PW) case, a forwarder on a terminating PE (T-PE) binds
>      a PW segment to an AC, while a forwarder on a switching PE (S-PE)
>      binds one PW segment to another PW segment.  In each direction
>      between the PEs, PW packets are transported by a PSN tunnel, which is
>      called a transport tunnel.
>
> SB> Did we ever your the term transport tunnel before?
>
> [yshen] This is mainly for clarity. We could change it to " which is
>      called a transport tunnel *in this document*". Or we can completely replace "transport tunnel" with just "tunnel".
>
> 3.  Reference Models and Failure Cases
>
>      The mechanism in this document intends to
>      use these topologies for local repair purposes.
>
> SB> The toplology is not a mechanism. Are you saying that the mechanims
> SB> only works in this topology?
>
> [yshen] No, these topologies are only examples for use by subsequent sections to describe the mechanisms. The mechanisms should equally work for other topologies as well.
>
>      This SHALL enable
>      local repair and global repair to work in tandem to achieve broader
>      coverage of protection for services.
>
> SB> I have no idea how a SHALL in capitals applies here.
>
> [yshen] Will fix this.
>
> 3.1.  Single-Segment PW
>
>
>
>                     |<-------------- PW1 --------------->|
>
>                 - PE1 -------------- P1 ---------------- PE2 -
>                /                                              \
>               /                                                \
>            CE1                                                  CE2
>               \                                                /
>                \                                              /
>                 - PE3 -------------- P2 ---------------- PE4 -
>
>                     |<-------------- PW2 --------------->|
>
>                                    Figure 1
>
>
>      Each CE is multi-homed to two PEs.  Hence, there are two divergent
>      paths between the CEs.
>
> SB> It does not follow that the paths are divergent! Who knows
> SB> what happens in the IP layer and the underlying transport
> SB> network.
>
>
> [yshen] We could rephrase this and remove "divergent". All we want to say here is that there are two distinct sets of AC-PW-AC between the CEs.
>
>      At any given time, each CE sends traffic via only one AC and receives
>      traffic via only one AC.  The two ACs MAY or MAY NOT be the same.
>
> SB> May not be the same what? If they are actually the same AC you
> SB> have no redundancy.
>
> [yshen] Will rephrase it. All we want to say is that at a given time, the CE may send traffic over one AC and receive traffic over another AC.
>
>      The AC used to send traffic is determined by the CE, and MAY rely on
>      an end-to-end OAM mechanism between the CEs.  The AC used for the CE
>      to receive traffic is determined by the state of the network and the
>      protection mechanism in use, as described later in this document.
>
>      From the perspective of traffic flowing towards a given CE, the set
>      of PWs, PEs and ACs involved can be viewed to serve primary and
>      backup (or active and standby) roles.  When the network is in a
>      steady state, the PW that is intended to carry the traffic is
>      referred to as a primary PW.  The PE at the egress of the primary PW
>      is a primary PE.  The AC connecting the CE and the primary PE is a
>      primary AC.  The other PW may be used to carry the traffic upon a
>      network failure, and is referred to as a backup PW.  The PE at the
>      egress of the backup PW is a backup PE.  The AC connecting the CE and
>      the backup PE is a backup AC.
>
>      In this document, the following primary and backup roles are assigned
>      for the traffic going from CE1 to CE2:
>
>         Primary PW: PW1
>
>
>
> Yimin Shen, et al.      Expires January 25, 2015                [Page 5]
>
>
> Internet-Draft     PW Endpoint Fast Failure Protection         July 2014
>
>
>         Primary PE: PE2
>
>         Primary AC: CE2-PE2
>
>         Backup PW: PW2
>
>         Backup PE: PE4
>
>         Backup AC: CE2-PE4
>
>      In this case, an egress AC failure refers to the failure of the AC
>      CE2-PE2.  An egress node failure refers to the failure of PE2.
>
>      The backup PE, backup PW and backup AC may be used to carry traffic
>      after a PW endpoint failure, when CE1 and CE2 switches traffic to PW2
>      in local repair or global repair, as described later in this
>      document.
>
>                      |<-------------- PW1 --------------->|
>
>                         ------------- P1 ---------------- PE2 -
>                        /                                       \
>                       /                                         \
>             CE1 -- PE1                                          CE2
>                       \                                         /
>                        \                                       /
>                         ------------- P2 ---------------- PE4 -
>
>                       |<-------------- PW2 --------------->|
>
>                                    Figure 2
>
>      Figure 2 shows another possible scenario, where CE1 is single-homed
>      to PE1, while CE2 remains multi-homed to PE2 and PE4.  From the
>      perspective of egress protection for the traffic from CE1 to CE2,
>      this topology is not much different than Figure 1.  However, for the
>
> SB> "not much different than Figure 1" is not helpful, either it is the
> same, or you need to explain the difference.
>
> [yshen] Will rephrase. The difference is actually described after "However...".
>
>
>      traffic in the direction from CE2 to CE1, PE1 must anticipate traffic
>      on both PW1 and PW2, and sends it to CE1 over the AC CE1-PE1.
>
> SB> What does it mean to anticipate traffic.
>
> [yshen] To anticipate incoming traffic over either PW1 or PW2. Will rephrase.
>
> 3.2.  Multi-Segment PW
>
>
>
>
>
>
>
>
>
>
>
> Yimin Shen, et al.      Expires January 25, 2015                [Page 6]
>
>
> Internet-Draft     PW Endpoint Fast Failure Protection         July 2014
>
>
>                     |<--------------- PW1 --------------->|
>                     |<----- SEG1 ----->|<----- SEG2 ----->|
>
>                - TPE1 -------------- SPE1 --------------- TPE2 -
>               /                                                 \
>              /                                                   \
>           CE1                                                     CE2
>              \                                                   /
>               \                                                 /
>                - TPE3 -------------- SPE2 --------------- TPE4 -
>
>                     |<----- SEG3 ----->|<----- SEG4 ----->|
>                     |<--------------- PW2 --------------->|
>
>                                    Figure 3
>
>      Figure 3 shows a topology that is similar to Figure 1 but in an MS-PW
>      environment.  PW1 and PW2 are both MS-PWs.  PW1 is established
>      between TPE1 and TPE2, and switched between segments SEG1 and SEG2 at
>      SPE1.  PW2 is established between TPE3 and TPE4, and switched between
>      segments SEG3 and SEG4 at SPE2.  CE1 is multi-homed to TPE1 and TPE3.
>      CE2 is multi-homed to TPE2 and TPE4.  The transport tunnels of the PW
>      segments are not shown in this figure for clarity.
>
>      In this document, the following primary and backup roles are assigned
>      for the traffic going from CE1 to CE2:
>
>         Primary PW: PW1
>
>         Primary T-PE: TPE2
>
>         Primary S-PE: SPE1
>
>         Primary AC: CE2-TPE2
>
>         Backup PW: PW2
>
>         Backup T-PE: TPE4
>
>         Backup S-PE: SPE2
>
>         Backup AC: CE2-TPE4
>
>      In this case, an egress AC failure refers to the failure of the AC
>      CE2-TPE2.  An egress node failure refers to the failure of TPE2.  An
>      S-PE failure refers to the failure of SPE1.
>
>
>
>
>
> Yimin Shen, et al.      Expires January 25, 2015                [Page 7]
>
>
> Internet-Draft     PW Endpoint Fast Failure Protection         July 2014
>
>
>      The backup T-PE, backup PW and backup AC are used for protecting the
>      primary PW against egress AC failure and egress node failure.  The
>      backup S-PE and the backup PW are used for protecting the primary PW
>      against S-PE failure, as described later in this document.
>
>      For consistency with the SS-PW scenario, primary T-PEs and a primary
>      S-PEs may simply be referred to as primary PEs in this document,
>      where specifics is not required.  Similarly, backup T-PEs and backup
>      S-PEs may be referred to as backup PEs.
>
> 4.  Theory of Operation
>
>      The fast protection mechanism in this document provides three types
>      of protection for PWs, corresponding to the three types of failures
>      described in Section 1.
>
>      a.  Egress AC protection
>
>      b.  Egress (T-)PE node protection
>
>      c.  S-PE node protection
>
>      The mechanism assumes a multi-homed CE with connectivity to a primary
>      PE and a backup PE, and the existence of a backup PW in the network.
>      In S-PE node protection, it also assumes the existence of a backup
>      S-PE on the backup PW.
>
>
> SB> Do the PWs need to be symmetric - could you have more
> S-PEs on one that you have on the other?
>
> [yshen] You could. For a given S-PE, as long as you can find another PE to serve as protector, it will work.
>
> 4.1.  Local Repair and Protector
>
>      The mechanism relies on local repair to be performed by routers
> SB> Do you mean routers or PEs? Routers of more likely LSRs
> operate at a different layer and have no business knowing about
> PWs.
>
> [yshen] routers (LSRs). Yes, they have no idea about PWs. This draft doesn't assume they know or care about PWs.
>
> SB> Has this work been reviewed my MPLS WG? I am concerned
> that you are doing a bunch of layer violation without explaining
> the how this is achieved or whether it is acceptable within the
> MPLS architecture.
>
> [yshen] There is no layer violation. The PLR simply redirect traffic from the original tunnel to a bypass tunnel, by doing a top label swap, without touching, changing or knowing the PW label. Please take a close look at the text.
>
>      upstream adjacent to failures.  Each of these routers is referred to
>      as a "point of local repair" (PLR).  A PLR MUST be able to detect a
>      failure by using a rapid mechanism, such as physical layer failure
>      detection, Bidirectional Failure Detection (BFD) (RFC 5880), etc.  In
>      anticipation of the failure, the PLR MUST also pre-establish a bypass
>      PSN tunnel to a "protector", and pre-install a bypass route in the
>      data plane.  The bypass tunnel MUST have the property that it will
>      not be affected by the topology changes in the event of the failure.
>
> SB> This is far too imprecise - you need to separate operations and
> topologies in the PW layer from operations and topologies in the
> PSN layer
>
> [yshen] Similar to existing IP/MPLS fast-reroute RFCs, this draft doesn't restrict local repair trigger to any specific failure detection mechanisms. Any mechanism will work.
>
> SB> In each case you need to be clear how you are detecting failure
> by specifying the MEPs and MIPs you are testing.
>
>      Upon detecting the failure, the PLR MUST invoke the bypass route in
>      the data plane, and reroute PW traffic to the protector through the
>      bypass tunnel.  The protector MUST in turn send the traffic to the
>      target CE.
>
> SB> No the protector knows nothing about CEs - they are in the client
> layer, and you can only protect at the server layer or the server's
> server layer.
>
> [yshen] In collocated model, the protector is a PE. In the centralized model, the protector may be an LSR , and it needs to participate in LDP PW signaling to understand PWs. See the related sections and LDP extensions in this draft. This centralized model is optional.
>
>      This procedure is referred to as local repair.
>
>      Different routers may serve as PLR and protector in different
>      scenarios.
>
> SB> Remember they are not routers - they are xPEs or LSRs.
>
> [yshen] Again, in collocated model, the protector is a PE. In the centralized model, the protector may be an LSR , and it needs to participate in LDP PW signaling to understand PWs. See the related sections and LDP extensions in this draft. But this centralized model is optional.
> [yshen] PLRs may be LSRs, but they don't need to know PWs, because all they do is to swap top label (tunnel label) to a bypass tunnel's label.
>
> SB> In each of the following we need to note that these are
> not RFC3985 PEs, even if they take no part in the protection
> such as the PEs on the left. Indeed I am wondering if you need
> to update RFC3985 and RFC5659
>
> [yshen] There is no need to update RFC3985 and RFC5659.
>
> Yimin Shen, et al.      Expires January 25, 2015                [Page 8]
>
>
> Internet-Draft     PW Endpoint Fast Failure Protection         July 2014
>
>
>      o  In egress AC protection, the PLR is the primary PE that terminates
>         the primary PW and hosts the primary AC, and the protector is the
>         backup PE (Figure 4).
>
>                     |<-------------- PW1 --------------->|
>
>                 - PE1 -------------- P1 ---------------- PE2 -
>                /                                         PLR  \
>               /                                           |    \
>            CE1                                      bypass|     CE2
>               \                                           |    /
>                \                                          |   /
>                 - PE3 -------------- P2 ---------------- PE4 -
>                                                       protector
>
>                     |<-------------- PW2 --------------->|
>
>                                    Figure 4
>
>
>      o  In egress PE node protection, the PLR is the penultimate hop
>         router of the transport tunnel of the primary PW, and the
>         protector is the backup PE (Figure 5).
>
>                     |<-------------- PW1 --------------->|
>
>                 - PE1 -------------- P1 ------- P3 ----- PE2 -
>                /                               PLR \          \
>               /                                     \          \
>            CE1                                 bypass\          CE2
>               \                                       \        /
>                \                                       \      /
>                 - PE3 -------------- P2 ---------------- PE4 -
>                                                       protector
>
>                     |<-------------- PW2 --------------->|
>
>                                    Figure 5
>
> SB> Note that it is nothing like as clean as this, if as you later have,
> some of P3's traffic needs to go to PE4 and some to PE5.
> Also what about the
>
> [yshen] Note that we are talking about a single PW, rather than multiple PWs carried by a single tunnel.
>
>      o  In S-PE node protection, the PLR is the penultimate hop router of
>         the transport tunnel of the primary PW segment, and the protector
>         is the backup S-PE (Figure 6).
>
>
>
>
>
>
>
>
>
>
> Yimin Shen, et al.      Expires January 25, 2015                [Page 9]
>
>
> Internet-Draft     PW Endpoint Fast Failure Protection         July 2014
>
>
>                     |<--------------- PW1 --------------->|
>                     |<----- SEG1 ----->|<----- SEG2 ----->|
>
>                - TPE1 ----- P4  ----- SPE1 -------------- TPE2 -
>               /             PLR \                               \
>              /                   \                               \
>           CE1               bypass\                               CE2
>              \                     \                             /
>               \                     \                           /
>                - TPE3 --------------- SPE2 -------------- TPE4 -
>                                    protector
>
>                     |<----- SEG3 ----->|<----- SEG4 ----->|
>                     |<--------------- PW2 --------------->|
>
>                                    Figure 6
>
>      A PLR can realize its role based on configuration or the signaling of
>      transport tunnel.  For example, in the case where the transport
>      tunnel is signaled by RSVP, the penultimate hop router could realize
>
> SB> Could realize is not sufficient. The mechanism needs to be
> unconditional.
>
> [yshen] Will rephrase.
>
>      that it is the PLR for egress (T-)PE or S-PE failure based on the RRO
>      in Resv message, which should indicate that the router is one hop
>      away from the PE.  The detail of how this could be achieved on a per-
>      protocol basis is out of the scope of this document.
>
> SB> So where is it in scope? How do I find out how to do it?
>
>      In all scenarios, when a PLR reroutes traffic through a bypass tunnel
>      to a protector during local repair, it MUST keep the label of the
>      primary PW intact in the packets.  This obviates the need for the PLR
>      to maintain bypass routes on a per-PW basis, and allows a single
>      bypass tunnel to carry traffic for multiple PWs.
>
> SB> OK, but didn't I read something about PE protecting subsets of the
> egress traffic of other PEs? How would that work without per PW information?
>
> [yshen] PWs to a given PE may be protected by multiple protectors. A set of PWs sharing the same protector X can be carried by the same tunnel (destined to the context ID of <primary PE, X>). PWs protected by a different protector Y must be carried by different tunnel (destined to the context ID of <primary PE, Y>). The PLR of each tunnel doesn't need to know PW info. All it does is to swap tunnel label to a bypass tunnel's label, and the bypass tunnel will guide the traffic to the intended protector.
>
>      The procedure also requires that the protector SHOULD be able to
>      forward the traffic based on a PW label that is assigned by the
>      primary PE, and ensure the traffic to eventually reach the target CE.
>      From the protector's perspective, this PW label is an upstream
>      assigned label (RFC 5331).
>
> SB> .. but the protector may be a P router and know nothing about
> PWs.
>
> [yshen] Again, in collocated model, the protector is a PE. In the centralized model, the protector may be an LSR , and it needs to participate in LDP PW signaling to understand PWs. See the related sections and LDP extensions in this draft. But this centralized model is optional.
>
>
>      To accomplish this, the protector SHOULD
>      learning the PW label from the primary PE prior to the failure, and
>      install proper forwarding state for the PW label in a dedicated label
>      space for the primary PE.
>
> SB> This is a new PE to P router protocol
>
> [yshen] The LDP extension is defined in a subsequent section.
>
>      During local repair, the protector SHOULD
>      perform PW label lookup in this label space.
>
> SB> This has to be signed off by MPLS WG
> SB> How can this only be a SHOULD - why is it not a MUST?
>
> [yshen] Will rephrase.
>
> SB> What do you do to ensure that they even have compatible label managers?
>
> [yshen] The LDP extensions defined in this draft covers how to negotiate the capability.
>
>
> SB> Doesn't this mean a P router looking up two labels to do
> the repair?
>
> [yshen] PLR only swaps the top label (i.e. tunnel label) to bypass label table, when doing the local repair.
>
>      The above examples have shown the scenarios where the protectors are
>      backup (T/S-)PEs.  In other scenarios, a protector may be a dedicated
>      router that assumes such role, separate from the backup (T/S-)PE of a
>      primary PW.  During local repair, the PLR MUST still reroute traffic
>      to the protector through a bypass tunnel.  The protector MUST in turn
>      send the traffic to the backup (T/S-)PE, which MUST then send the
>
>
>
>
> Yimin Shen, et al.      Expires January 25, 2015               [Page 10]
>
>
> Internet-Draft     PW Endpoint Fast Failure Protection         July 2014
>
>
>      traffic to the target CE via a backup AC or a backup PW segment.
>      More detail will be described in Section 4.3.
>
> 4.2.  Context Identifier
>
>      A protector MAY protect multiple primary PEs.
>
> SB> This requires that a P router knows about PWs - how does
> it do that?
>
> [yshen] The protector will perform context label forwarding. The bypass tunnel points to a context label table, and the protector looks up the PW label in that table.
>
>      The protector MUST
>      maintain a separate label space for each primary PE.  Likewise, the
>      PWs terminated on a primary PE MAY be protected by multiple
>      protectors, each for a subset of the PWs.  In any case, a given
>      primary PW SHOULD be associated with one and only one pair of
>      {primary PE, protector}.
>
>      An IPv4/v6 address is assigned to each ordered pair of {primary PE,
>      protector} to facilitate protection establishment.  This address is
>      referred to as a "context identifier".  It MUST be globally unique,
>      or unique in the address space of the network where the primary PE
>      and the protector reside.
>
> SB> I think you need to make clear that this is not backwards compatible
> with existing PW PEs.
>
> [yshen] PEs will need to support the extensions defined by this draft.
>
> SB> You also need to explain how the IP based context identifier
> mechanism works. Is it in the control plane or the data plane?
>
> 4.2.1.  Semantics
>
>      The semantics of a context identifier is twofold.
>
>      o  It identifies a primary PE and an associated protector.  In other
>         words, it identifies a primary PE on a per protector basis.  A
>         given primary PE may be protected by multiple protectors, each for
>         a subset of the primary PWs terminated on the primary PE.  A
>         distinct context identifier MUST be assigned to the primary PE and
>         each protector.
>
>         For each primary PW, its ingress PE MUST set up or resolve a
>         transport tunnel with destination as the context identifier of the
>         {primary PE, protector}, rather than a private IP address of the
>         primary PE.  This not only allows the transport tunnel to reach
>         the primary PE, but also conveys the identity of the protector to
>         the PLR(s) along the transport tunnel.  Each PLR can in turn use
>         this information to set up a bypass tunnel to the protector
>         without relying on local configuration.
>
>      o  It indentifies the primary PE's label space on the protector.  The
>         protector may protect PWs for multiple primary PEs.  For each
>         primary PE, it MUST maintain a separate label space to store the
>         PW labels assigned by that primary PE.  It MUST associate a PW
>         label with a label space via the context identifier of the
>         {primary PE, protector}, as described below.
>
> SB> Is this context identifier an IP address or an MPLS label? Where
> is it carried?
>
> [yshen] a context identifier is an IP address. If the tunnel is IP tunnel, it is carried in IP header as dest address. If the tunnel is MPLS tunnel, it is indicated by the label.
>
>         In addition to the normal LDP PW signaling, the primary PE MUST
>         have a targeted LDP session with the protector, and advertise PW
>         labels to the protector via LDP Label Mapping messages (See
>
>
>
> Yimin Shen, et al.      Expires January 25, 2015               [Page 11]
>
>
> Internet-Draft     PW Endpoint Fast Failure Protection         July 2014
>
>
>         Section 5 for detail).  The primary PE MUST attach the context
>         identifier to each message.  Upon receiving the message, the
>         protector MUST install the advertised PW label in the label space
>         identified by the context identifier.
>
> SB> I am currently confused about how a data packet carries the PW
> label provided by another PE.
>
>         When a PLR sets up or resolve a bypass tunnel to the protector, it
>         MUST set the destination to the context identifier, rather than a
>         private IP address of the protector.  Once established, the bypass
>         tunnel, with either its MPLS label or IP tunnel destination
>         address, is used as the identifier of label space.  On the
>         protector, all PW packets received on the bypass tunnel MUST be
>         forwarded based on a label lookup in that label space.
>
> SB> I do not understand the data plane structure that the above sentence
> is describing.
>
> [yshen] This is basically the context label forwarding paradigm (RFC 5331). From the protector's perspective, the bypass tunnel serves as a context, and indicates the label space of the primary PE where the PW label must be looked up.
>
>
> 4.2.2.  Advertisement and Path Computation
>
>      Using a context identifier as destination for both transport tunnel
>      and bypass tunnel requires both the primary PE and the protector to
>      advertise the context identifier via IGP as an IP address reachable
>      through both routers in routing domain and/or TE domain.  This
>      imposes the following requirements on path computation for these
>      tunnels.
>
>      o  For the transport tunnel, the ingress PE MUST choose the primary
>         PE as the actual endpoint.
>
>      o  For the bypass tunnel, the PLR MUST choose the protector as the
>         actual endpoint.  In egress (T-)PE node protection and S-PE node
>         protection, the bypass tunnel MUST avoid the primary (S-)PE.
>
>      The detail of how the primary PE and the protector may advertise a
>      context identifier is independent of this mechanism and out of the
>      scope of this document.
>
> SB> Given that you give signalling data structures later, I am confused
> as to how this can be out of scope of this text. Surely this is needed
> to implement an interoperable solution?
>
> [yshen] There is no new extension needed for IGP. Both PEs advertise the context ID. That's it. Will rephrase it.
>
>      One approach would be to advertise it as a
>      virtual proxy node connected to both routers, with the link between
>      the proxy node and the primary PE having a more preferable IGP or TE
>      metric than the link between the proxy node and the protector.  The
>      ultimate goal is for a path computation algorithm, such as CSPF
>      (constrained shortest path first), LFA (RFC 5286) and MRT ([IP-LDP-
>      FRR-MRT]), to be able to compute the paths that meet the above
>      requirements.
>
> 4.3.  Protection Models
>
>      There are two protection models based on the location of a protector.
>      A network MAY use either model, or a combination of both.
>
>
>
>
>
>
>
> Yimin Shen, et al.      Expires January 25, 2015               [Page 12]
>
>
> Internet-Draft     PW Endpoint Fast Failure Protection         July 2014
>
>
> 4.3.1.  Co-located Protector
>
>      In this model, the protector is a backup PE that is directly
>      connected to the target CE via a backup AC, or it is a backup S-PE on
>      a backup PW.  That is, the protector is co-located with the backup
>      (S-)PE.  Examples of this model have been introduced in Figure 4,
>      Figure 5 and Figure 6 in Section 4.1.
>
>      In egress AC protection and egress PE node protection, when a
>      protector receives traffic from the PLR, it forwards the traffic to
>      the CE via the backup AC.  This is shown in Figure 7, where PE2 is
>      the PLR for egress AC failure, P3 is the PLR for PE2 failure, and PE4
>      (the backup PE) is the protector.
>
>                    |<-------------- PW1 --------------->|
>
>                - PE1 -------------- P1 ------- P3 ----- PE2 ----
>               /                               PLR \     PLR     \
>              /                                     \     |       \
>           CE1                                 bypass\    |bypass  CE2
>              \                                       \   |       /
>               \                                       \  |      /
>                - PE3 -------------- P2 ---------------- PE4 ----
>                                                  protector
>
>                    |<-------------- PW2 --------------->|
>
>                                    Figure 7
>
>      In S-PE node protection, when a protector receives traffic from the
>      PLR, it MUST forward the traffic via the next segment of the backup
>      PW.  The T-PE of the backup PW MUST in turn forward the traffic to
>      the CE via a backup AC.  This is shown in Figure 8, where P4 is the
>      PLR for SPE1 failure, and SPE2 (the backup S-PE) is the protector for
>      SPE1.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Yimin Shen, et al.      Expires January 25, 2015               [Page 13]
>
>
> Internet-Draft     PW Endpoint Fast Failure Protection         July 2014
>
>
>                     |<--------------- PW1 --------------->|
>                     |<----- SEG1 ----->|<----- SEG2 ----->|
>
>                - TPE1 ----- P4  ----- SPE1 -------------- TPE2 -
>               /             PLR \                               \
>              /                   \                               \
>           CE1               bypass\                               CE2
>              \                     \                             /
>               \                     \                           /
>                - TPE3 --------------- SPE2 -------------- TPE4 -
>                                protector
>
>                     |<----- SEG3 ----->|<----- SEG4 ----->|
>                     |<--------------- PW2 --------------->|
>
>                                    Figure 8
>
>      In the co-located protector model, the number of context identifiers
>      needed by a network is the number of distinct {primary PE, backup PE}
>      pairs.  From the perspective of scalability, the model is suitable
>      for networks where the number of backup PEs for any given primary PE
>      is relatively small.
>
> 4.3.2.  Centralized Protector
>
>      In this model, the protector is a dedicated P router or PE router
>      that serves the role.  In egress AC protection and egress PE node
>      protection, the protector MAY or MAY NOT be a backup PE with a direct
>      connection to the target CE.  In S-PE node protection, the protector
>      MAY or MAY NOT be a backup S-PE on the backup PW.
>
>      In egress AC protection and egress PE node protection, when the
>      protector receives traffic from the PLR, if the protector has a
>      direct connection (i.e. backup AC) to the CE, it MUST forward the
>      traffic to the CE via the backup AC, which is similar to Figure 7.
>      Otherwise, it MUST forward the traffic to a backup PE, which MUST
>      then forward the traffic to the CE via a backup AC.  This is shown in
>      Figure 9, where the protector receives traffic from P3 (the PLR for
>      egress PE failure) or PE2 (the PLR for egress AC failure) and
>      forwards the traffic to PE4 (the backup PE).  The protector may be
>      protecting other PWs as well, which is not shown in this figure for
>      clarity.
>
> SB> If you are going to cover the shared case, I think you need to
> make it much clearer how the PWs are identified from the received
> data packets.
>
>
>
>
>
>
>
>
> Yimin Shen, et al.      Expires January 25, 2015               [Page 14]
>
>
> Internet-Draft     PW Endpoint Fast Failure Protection         July 2014
>
>
>                     |<------------- PW1 --------------->|
>
>                 - PE1 ------------- P1 ------- P3 ----- PE2 --
>                /                              PLR \     PLR   \
>               /                                    \     /     \
>              /                                bypass\   /bypass \
>             /                                        \ /         \
>          CE1                                      protector       CE2
>             \                                         \          /
>              \                                         \        /
>               \                                         \      /
>                \                                         \    /
>                 - PE3 ------------- P2 -----------------PE4 --
>
>                     |<------------- PW2 --------------->|
>
>                                    Figure 9
>
>      In S-PE node protection, when the protector receives traffic from the
>      PLR, if the protector is a backup S-PE of the backup PW, it MUST
>      forward the traffic via the next segment of the backup PW, and the
>      T-PE of the backup PW MUST forward the traffic to the CE via a backup
>      AC, which is similar to Figure 8.  Otherwise, the protector MUST
>      first forward the traffic to the backup S-PE, which MUST then forward
>      the traffic via the next segment of the backup PW.  Finally, the T-PE
>      of the backup PW MUST forward the traffic to the CE via a backup AC.
>      This is shown in Figure 10, where the protector forwards traffic to
>      SPE2 (the backup S-PE), SPE2 forwards the traffic to TPE4 via SEG4,
>      and TPE4 finally forwards traffic to CE2.  The protector may be
>      protecting other PW segments as well, which is not shown in this
>      figure for clarity.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Yimin Shen, et al.      Expires January 25, 2015               [Page 15]
>
>
> Internet-Draft     PW Endpoint Fast Failure Protection         July 2014
>
>
>                     |<--------------- PW1 --------------->|
>                     |<----- SEG1 ----->|<----- SEG2 ----->|
>
>                - TPE1 ----- P4  ----- SPE1 -------------- TPE2 -
>               /             PLR \                               \
>              /                   \                               \
>             /               bypass\                               \
>            /                       \                               \
>         CE1                     protector                           CE2
>            \                        \                              /
>             \                        \                            /
>              \                        \                          /
>               \                        \                        /
>                - TPE3 --------------- SPE2 -------------- TPE4 -
>
>                     |<----- SEG3 ----->|<----- SEG4 ----->|
>                     |<--------------- PW2 --------------->|
>
>                                    Figure 10
>
>      The centralized protector model provides the convenience for multiple
>      primary PEs to share one protector.  Each primary PE MAY only need
>      the one protector to protect all of its PWs.  From the perspective of
>      scalability, the number of context identifiers needed by a network
>      MAY be bound to the number of primary PEs.
>
> 4.4.  Transport Tunnel
>
>      The ingress PE of a primary PW associates the PW with the primary
>      egress PE through LDP signaling.  In addition, as mentioned in
>      Section 4.2.1, the ingress PE MUST associate the transport tunnel of
>      the PW with the context identifier of the {primary PE, protector},
>      and set up or resolve the transport tunnel by using the context
>      identifier as destination.  This not only ensures that PW traffic be
>      transported to the primary PE, but also facilitates bypass tunnel
>      establishment at PLR(s), as the context identifier implies the
>      identity of the protector as well.  This is also the case for a
>      multi-segment PW, where the ingress PE and egress PE are T/S-PEs.
>
>      The association between the transport tunnel and the context
>      identifier at the ingress PE MAY be achieved by configuration or an
>      auto-discovery mechanism.  In the later case, the ingress PE MAY
>      learn the context identifier from the primary (egress) PE, if the
>      primary PE advertises the context identifier as "third party next
>      hop" in IPv4/v6 Interface_ID  (RFC 3471, RFC 3472) in the LDP
>      Label Mapping message of the primary PW.
>
>
>
>
>
> Yimin Shen, et al.      Expires January 25, 2015               [Page 16]
>
>
> Internet-Draft     PW Endpoint Fast Failure Protection         July 2014
>
>
> 4.5.  Bypass Tunnel
>
>      A PLR may protect multiple PWs associated with one or multiple pairs
>      of {primary PE, protector}. The PLR MUST establish a bypass tunnel to
>      each protector for each distinct context identifier associated with
>      that protector.  The destination of the bypass tunnel MUST be the
>      context identifier (Section 4.2.1).  The PLR may derive the context
>      identifier from the destination of the transport tunnel that
>      traverses it.
>
>      For examples, in Figure 7 and Figure 9, a bypass tunnel is
>      established from PE2 (PLR for egress AC failure) to the protector,
>      and another bypass tunnel is established from P3 (PLR for egress node
>      failure) to the protector.  In Figure 8 and Figure 10, a bypass
>      tunnel is established from P4 (PLR for S-PE failure) to the
>      protector.
>
>      During local repair, the PLR reroutes traffic to the protector
>      through a bypass tunnel with PW label intact in the packets.  This
>      normally involves pushing a label to the label stack, if the bypass
>      tunnel is an MPLS tunnel, or pushing an IP header to the packets, if
>      the bypass tunnel is an IP tunnel.
>
> SB> Surely it is normally a swap?
>
> [yshen] yes, this is just a label swap of the top label, from tunnel label to bypass tunnel label.
>
> SB> I am somewhat confused about what this all looks like when this is
> IP. The only PS/IP other than for SATOP are defined by L2TPv3 WG.
> There is no IP MS-PW definition that I am aware of. I think you need
> to be much clearer about what is going on when you discuss PW over IP
> egress repair.
>
>      The protector MUST in turn
>      forward the traffic based on the PW label.  To achieve such kind of
>      forwarding, the protector MUST rely on the bypass tunnel as a context
>      to determine the primary PE's label space.  If the bypass tunnel is
>      an MPLS tunnel, the protector MUST have assigned a non-reserved label
>      to the bypass tunnel during the establishment of the bypass tunnel,
>      and hence this label can serve as the context.  If the bypass tunnel
>      is an IP tunnel, the protector can simply rely on the context
>      identifier carried as the destination address in IP header.
>
>      A bypass tunnel MUST have the property that it is not affected by the
>      topology changes caused by the failure.  Therefore, it can be used to
>      transmit traffic for local repair.  It SHOULD remain effective, until
>      the traffic is moved to another fully functional egress AC, PW and/or
>      transport tunnel.
>
> 4.6.  Forwarding State on Protector
>
>      A protector MUST learn PW labels from all the primary PEs that it
>      protects (Section 5.2), and maintain the PW labels in respective
>      label spaces of the primary PEs.  In the control plane, a label space
>      is identified by the context identifier of a pair of {primary PE,
>      protector}. In the forwarding plane, it is indicated by the bypass
>      tunnel(s) destined for the context identifier.
>
> SB> Are you saying that this mechanism mandates no PHP?
>
> [yshen] It mandates PHP for bypass tunnels only, as their labels serve as contexts on protectors. This is not mandatory for normal tunnels.
>
>
>
>
> Yimin Shen, et al.      Expires January 25, 2015               [Page 17]
>
>
> Internet-Draft     PW Endpoint Fast Failure Protection         July 2014
>
>
> 4.6.1.  Examples of Co-located Protector
>
>      In Figure 7, PE4 is a co-located protector that protects PW1 against
>      egress AC failure and egress node failure.  It maintains a label
>      space for PE2, which is identified by the context identifier of {PE2,
>      PE4}. It learns PW1's label from PE2, and installs an forwarding
>      entry for the label in that label space.  The nexthop of the
>      forwarding entry indicates a label pop with outgoing interface
>      pointing to the backup AC CE2-PE4.
>
> SB> I am not sure what you are describing in the above. Is this an
> MPLS operation or a PW operation. If the latter it is not a simple
> label pop.
>
> [yshen] It is PW label pop.
>
>      In Figure 8, SPE2 is a co-located protector that protects PW1 against
>      S-PE failure.  It maintains a label space for SPE1, which is
>      identified by the context identifier of {SPE1, SPE2}. It learns
>      SEG1's label from SPE1, and installs a forwarding entry in the label
>      space.  The nexthop of the forwarding entry indicates a label swap to
>      SEG4's label.
>
> 4.6.2.  Examples of Centralized Protector
>
>      In the centralized protector model, for each primary PW of which the
>      protector is not a backup (S-)PE, the protector MUST also learn the
>      label of the backup PW from the backup (S-)PE (Section 5.3).  This is
>      the backup (S-)PE that the protector will forward traffic to.  The
>      protector MUST install a forwarding entry with label swap from the
>      primary PW's label to the backup PW's label.
>
>      In Figure 9, the protector is a centralized protector that protects
>      PW1 against egress AC failure and egress node failure.  It maintains
>      a label space for PE2, which is identified by the context identifier
>      of {PE2, protector}. It learns PW1's label from PE2, and PW2's label
>      from PE4.  It installs a forwarding entry for PW1's label in the
>      label space.  The nexthop of the forwarding entry indicates a label
>      swap to PW2's label.
>
>      In Figure 10, the protector is a centralized protector that protects
>      the PW segment SEG1 of PW1 against the node failure of SPE1.  It
>      maintains a label space for SPE1, which is identified by the context
>      identifier of {SPE1, protector}. It learns SEG1's label from SPE1,
>      and learns SEG3's label from SPE2.  It installs a forwarding entry
>      for SEG1's label in the label space.  The nexthop of the forwarding
>      entry indicates a label swap to SEG3's label.
>
> 5.  LDP Extensions
>
>      As described in previous sections, a targeted LDP session MUST be
>      established between each pair of primary PE and protector.  The
>      primary PE sends Label Mapping message over this session to advertise
>      primary PW labels to the protector.  In the centralized protector
>
>
>
> Yimin Shen, et al.      Expires January 25, 2015               [Page 18]
>
>
> Internet-Draft     PW Endpoint Fast Failure Protection         July 2014
>
>
>      model, a targeted LDP session MUST also be established between a
>      backup (S-)PE and a protector.  The backup PE sends Label Mapping
>      message over this session to advertise backup PW labels to the
>      protector.
>
>      To facilitate the procedures, this document defines a new "Protection
>      FEC Element" TLV.  The Label Mapping messages of both the LDP
>      sessions above MUST carry this TLV to indicate the identity of a
>      primary PW.  Specifically, in the centralized protector model, the
>      Protection FEC Element TLV advertised by a backup (S-)PE MUST match
>      the one advertised by the primary PE, so that the protector can
>      associate the primary PW's label with the backup PW's label, and
>      perform a label swap.
>
>      This document also defines the encoding of Capability Parameter TLV
>      (RFC 5561) for a new "Egress Protection Capability", to allow a
>      protector to announce its capability of processing the above
>      Protection FEC Element TLV and performing context specific label
>      switching for PW labels.
>
>      The procedures in this section are only applicable, if the protector
>      advertises the Egress Protection Capability, the primary PE supports
>      the advertisement of the Protection FEC Element TLV, and in the
>      centralized protector model, the backup PE also supports the
>      advertisement of the Protection FEC Element TLV.
>
> 5.1.  Egress Protection Capability TLV
>
>      A protector MUST advertise the Egress Protection Capability TLV in
>      its Initialization message and Capability message, over the LDP
>      session with a primary PE.  In the centralized protector model, the
>      protector MUST also advertise the TLV over the LDP session with a
>      backup PE.  The TLV carries one or multiple context identifiers.  To
>      the primary PE, the TLV SHOULD carry the context identifier of the
>      {primary PE, protector}. In the centralized protector model, the TLV
>      SHOULD carry to the backup PE multiple context identifiers, one for
>      each {primary PE, protector} where the backup PE serves as a backup
>      for the primary PE.  This TLV SHOULD NOT be advertised by the primary
>      PE or the backup PE to the protector.
>
>      The processing of the Egress Protection Capability TLV by a receiving
>      router SHOULD follow the procedures defined in RFC 5561.  In
>      particular, the router SHOULD advertise PW information to the
>      protector by using the Protection FEC Element TLV, only after it has
>      received the Egress Protection Capability TLV from the protector.  It
>      SHOULD validate each context identifier included in the TLV, and
>      advertise the information of only those PWs that are associated with
>      the context identifier.  It SHOULD withdraw previously advertised
>
>
>
> Yimin Shen, et al.      Expires January 25, 2015               [Page 19]
>
>
> Internet-Draft     PW Endpoint Fast Failure Protection         July 2014
>
>
>      Protection FEC TLVs, when the protector has withdrawn a previously
>      advertised context identifier or the entire Egress Protection
>      Capability TLV via Capability message.
>
>      The encoding of the Egress Protection Capability TLV is defined as
>      below.  It conforms to the format of Capability Parameter TLV
>      specified in RFC 5561.
>
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |U|F|  Egress Protection (TBD)  |              Length           |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |S| Reserved    |                                               |
>        +-+-+-+-+-+-+-+-+                                               |
>        |                                                               |
>        ~                Capability Data = context identifier(s)        ~
>        |                                                               |
>        |                                               +-+-+-+-+-+-+-+-+
>        |                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>                                    Figure 11
>
>      The U-bit MUST be set to 1 so that a receiver MUST silently ignore
>      this TLV if unknown to it, and continue processing the rest of the
>      message.
>
>      The F-bit MUST be set to 0 since this TLV is sent only in
>      Initialization and Capability messages, which are not forwarded.
>
>      The TLV Code Point is TBD.  It needs to be assigned by IANA.
>
>      The S-bit indicates whether the sender is advertising (S=1) or
>      withdrawing (S=0) the capability.
>
>      The "Capability Data" is encoded with the context identifier of the
>      {primary PE, protector}.
>
> SB> where is the structure of {primary PE, protector} defined?
>
> [yshen] The Protection FEC Element TLV carries the context ID of {primary PE, protector}. The {primary PE, protector} tuple itself is not encoded.
>
> 5.2.  PW Label Distribution from Primary PE to Protector
>
>      A primary PE SHOULD advertise a primary PW's label to a protector by
>      sending a Label Mapping message.  The message includes a Protection
>      FEC Element TLV (see Section 5.4 for encoding), and an Upstream-
>      Assigned Label TLV (RFC 6389) encoded with the PW's label.  The
>      combination of the Protection FEC Element TLV and the PW label
>      represents the primary PE's forwarding state for the PW.  The Label
>      Mapping message SHOULD also carry an IPv4/v6 Interface_ID TLV (RFC
>
>
>
> Yimin Shen, et al.      Expires January 25, 2015               [Page 20]
>
>
> Internet-Draft     PW Endpoint Fast Failure Protection         July 2014
>
>
>      6389, RFC 3471) encoded with the context identifier of the {primary
>      PE, protector}.
>
>      The protector that receives this Label Mapping message SHOULD install
>      a forwarding entry for the PW label in the label space identified by
>      the context identifier.  The nexthop of the forwarding entry SHOULD
>      ensure packets to be sent towards the target CE via a backup AC or a
>      backup (S-)PE, depending on the protection scenario.  The protector
>      SHOULD silently discard a Label Mapping message if the included
>      context identifier is unknown to it.
>
> 5.3.  PW Label Distribution from Backup PE to Protector
>
>      In the centralized protector model, a backup PE SHOULD advertise a
>      backup PW's label to a protector by sending a Label Mapping message.
>      The message includes a Protection FEC Element TLV and a Generic Label
>      TLV encoded with the backup PW's label.  This Protection FEC Element
>      MUST be identical to the Protection FEC Element TLV that the primary
>      PE advertises to the protector (Section 5.2).  The context identifier
>      SHOULD NOT be encoded in Interface_ID TLV in this message.
>
>      The protector that receives this Label Mapping message SHOULD
>      associate the backup PW with the primary PW, based on the common
>      Protection FEC Element TLV.  It SHOULD distinguish between the Label
>      Mapping message from the primary PE and the Label Mapping message
>      from the backup PE based on the respective presence and absence of
>      context identifier in Interface_ID TLV.  It SHOULD install a
>      forwarding entry for the primary PW's label in the label space
>      identified by the context identifier.  The nexthop of the forwarding
>      entry SHOULD indicate a label swap to the backup PW's label, followed
>      by a label push or IP header push for a transport tunnel to the
>      backup PE.
>
> 5.4.  Protection FEC Element TLV
>
>      The Protection FEC Element TLV has type 0x83.  Its format is defined
>      as below:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Yimin Shen, et al.      Expires January 25, 2015               [Page 21]
>
>
> Internet-Draft     PW Endpoint Fast Failure Protection         July 2014
>
>
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |   Type(0x83)  |    Reserved   | Encoding Type |    Length     |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                                                               |
>        |                                                               |
>        ~                         PW Information                        ~
>        |                                                               |
>        |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>                                    Figure 12
>
>      - Encoding Type
>
>         Type of format that PW Information field is encoded.
>
>      - Length
>
>         Length of PW Information field in octets.
>
>      - PW Information
>
>         Field of variable length that specifies a PW
>
>      For Encoding Type, 1 is defined for the PWid FEC Element format, and
>      2 is defined for the Generalized PWid FEC Element format (RFC 4447).
>
>
> 5.4.1.  Encoding Format for PWid
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Yimin Shen, et al.      Expires January 25, 2015               [Page 22]
>
>
> Internet-Draft     PW Endpoint Fast Failure Protection         July 2014
>
>
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |   Type(0x83)  |    Reserved   |  Enc Type(1)  |   Length(16)  |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                      Ingress PE Address                       |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                       Egress PE Address                       |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                            Group ID                           |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                             PW ID                             |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |C|           PW Type           |           Reserved            |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>                                    Figure 13
>
>      - Ingress PE Address
>
>         IP address of the ingress PE of PW.
>
>      - Egress PE Address
>
>         IP address of the egress PE of PW.
>
> SB> How does this work for IPv6?
>
>      - Group ID
>
>         An arbitrary 32-bit value that represents a group of PWs and that
>         is used to create groups in the PW space.
>
>      - PW ID
>
>         A non-zero 32-bit connection ID that, together with the PW Type
>         field, identifies a particular PW.
>
>      - Control word bit (C)
>
>         A bit that flags the presence of a control word on this PW.  If C
>         = 1, control word is present; If C = 0, control word is not
>         present.
>
>      - PW Type
>
>         A 15-bit quantity that represents the type of PW.
>
> SB> Needs a ref
>
>
>
>
> Yimin Shen, et al.      Expires January 25, 2015               [Page 23]
>
>
> Internet-Draft     PW Endpoint Fast Failure Protection         July 2014
>
>
> 5.4.2.  Encoding Format for Generalized PWid
>
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |   Type(0x83)  |    Reserved   |  Enc Type(2)  |   Length      |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                      Ingress PE Address                       |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                       Egress PE Address                       |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |C|           PW Type           |           Reserved            |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |   AGI Type    |    Length     |      Value                    |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        ~                    AGI  Value (contd.)                        ~
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |   AII Type    |    Length     |      Value                    |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        ~                   SAII  Value (contd.)                        ~
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |   AII Type    |    Length     |      Value                    |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        ~                   TAII Value (contd.)                         ~
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>                                    Figure 14
>
>      - Ingress PE Address
>
>         IP address of the ingress PE of PW.
>
>      - Egress PE Address
>
>         IP address of the egress PE of PW.
>
> SB> IPv6?
>
>      - Control word bit (C)
>
>         A bit that flags the presence of a control word on this PW.  If C
>         = 1, control word is present; If C = 0, control word is not
>         present.
>
>      - PW Type
>
>         A 15-bit quantity that represents the type of PW.
>
>
>
> Yimin Shen, et al.      Expires January 25, 2015               [Page 24]
>
>
> Internet-Draft     PW Endpoint Fast Failure Protection         July 2014
>
>
>      - AGI Type, Length, Value, AGI Value
>
>         Attachment Group Identifier of PW.
>
>      - SAII Type, Length, Value, SAII Value
>
>         Source Attachment Individual Identifier of PW.
>
>      - TAII Type, Length, Value, TAII Value
>
>         Target Attachment Individual Identifier of PW.
>
> 6.  Revertive Behavior
>
>      Subsequent to local repair, there are three strategies for the
>      network to restore traffic to a fully functional PW.
>
>      o  Global revertive mode
>
>         If the ingress CE is multi-homed (Figure 1), it MAY switch the
>         traffic to a backup AC which is bound to a backup PW.
>         Alternatively, if the ingress PE hosts a backup PW (Figure 2), the
>         ingress PE MAY switch the traffic to the backup PW.  These
>         procedures are referred to as global repair.  Possible triggers of
>         a global repair include PW status, OAM, and BFD.
>
>      o  Control plane revertive mode
>
>         In egress PE node protection and S-PE node protection, it is
>         possible that the failure is limited to the link between the PLR
>         and the primary (S-)PE, whereas the primary (S-)PE is still up.
>         In this case, the PLR or an upstream router along the transport
>         tunnel MAY reroute the tunnel around the failed link via an
>         alternative path.  Thus, the transport tunnel can continue to be
>         used to carry the PW traffic to the primary (S-)PE.  This
>         procedure is driven by control plane convergence, and is referred
>         to as control plane repair.
>
>      o  Local revertive mode
>
>         The PLR MAY move traffic back to the primary PW, after the failure
>         is resolved.  In egress AC protection, upon detecting that the
>         primary AC is restored, the PLR MAY start forwarding traffic over
>         the AC again.  Likewise, in egress PE node protection and S-PE
>         node protection, upon detecting that the primary PE is restored,
>         the PLR MAY re-establish the primary transport tunnel through the
>         primary PE, and move the traffic from the bypass tunnel back to
>
>
>
>
> Yimin Shen, et al.      Expires January 25, 2015               [Page 25]
>
>
> Internet-Draft     PW Endpoint Fast Failure Protection         July 2014
>
>
>         the transport tunnel.  These procedures are referred to as local
>         reversion.
>
>      The fast protection mechanism in this document SHOULD be used in
>      tandem with the global revertive mode.  Particularly in the case of
>      egress (S-)PE failure, if the ingress PE or the protector loses
>      communication with the (S-)PE for an extensive period of time, the
>      LDP session between them may go down.  Consequently, the ingress PE
>      may bring down the primary PW, or the protector may remove the
>      forwarding entry of the primary PW label.  In either case, the
>      service will be disrupted.  In other words, although the fast
>      protection can temporarily repair traffic, control plane state may
>      eventually be timed out if the failure persists.  Therefore, it is
>      recommended that the global revertive mode SHOULD be set up in
>      advance, so that traffic can be moved to a fully functional backup PW
>      shortly after the local repair.
>
>      The control plane revertive mode may always happen as part of the
>      convergence of control plane protocols.  However, it is only
>      applicable to the specific scenarios described above.
>
>      The local revertive mode is optional.  In the circumstances where the
>      failure is caused by resource flapping, local reversion MAY be
>      dampened to limit potential disruptions.  Local revertive mode MAY be
>      disabled completely by configuration.
>
> 7.  IANA Considerations
>
>      This document defines the encoding of the Capability Parameter TLV
>      for the new "Egress Protection Capability" in Section 5.  This would
>      require IANA to assign a TLV Code Point to it.
>
>      This document defines a new LDP Protection FEC Element TLV in
>      Section 5.  IANA has assigned the type value 0x83 to it.
>
> SB> I am very confused about what explicit actions you are asking IANA
> to take. Are you saying that there are no IANA actions?
>
> [yshen] Need IANA to assign a TLV code to "Egress Protection Capability", as said above.
>
> 8.  Security Considerations
>
>      The security considerations discussed in RFC 5036, RFC 5331, RFC
>      3209, and RFC 4090 apply to this document.
>
> SB> Are there any PW security considerations that apply?
>
> SB> This is a new PW operational mode, so I am surprised that there are
> no new security considerations. An early security review might be useful.
>
>
> [yshen] Not sure about any specific security issues.
>
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
> .
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 5 Aug 2014 11:14:05 +0000

Stewart, Yimin and all,
A couple of comments/questions inline below.

Regards,
       Sasha 
Email: [email-masked]
Mobile: 054-9266302

> Sent: Tuesday, August 05, 2014 1:56 PM
> To: Yimin Shen; pwe3; [email-masked]
> Cc: [email-masked]
> > Thanks very much for the detailed review and comments. I'd like to
> highlight a few things below about this draft, and then respond to your
> comments inline. Hope you could give the draft another closer look.
> Yimin,
> 
[[Sasha]] I still have serious doubts regarding LDP-based MPLS PSN - at least without some extensions to LDP.
> > [1] This draft is completely based on the PWE3 and the MS-PW
> architecture. It is also based on RFC 5331 " MPLS Upstream Label Assignment
> and Context-Specific Label Space". So ideally readers should be familiar with
> that RFC.
[[Sasha]] yes, RFC 4447 explicitly requires the PW labels to be allocated from the per-platform label space. 
And according to RFC 5331 per-platform label space is a special case of the label context.  
> this text and the associated references.
[[Sasha]] How is the router supposed to differentiate between an IP address used as the context ID and an IP address used as the PE ID?
> > [3] PLR performs local repair in dataplane, based on pre-installed backup
> forwarding state pointing to a bypass tunnel. There is no control-plane
> involvement in local repair.
> > This is similar to the existing IP/MPLS fast-reroute mechanisms. Therefore,
> it can achieve restore traffic with a similar performance to those
> mechanisms. That is the main goal of this draft.
> > [4] When doing local repair, the PLR only swaps the top label (i.e. tunnel
> label) to a bypass tunnel's label, and keeps the PW label (allocated by
> primary/protected PE) intact. The PLR doesn't need to know or understand
> the PW label.
> > [5] The protector is the router at the other end of the bypass tunnel. It is
> responsible for forwarding the traffic further, so that the traffic can
> eventually reach the target CE. The protector must understand the PW label
> allocated by the primary PE.
> > This is achieved by using the context label forwarding paradigm specified in
> RFC 5331. This draft defines some LDP extensions to allow the primary PE to
> advertise PW labels to the protector. The protector locally maintains a label
> space for these PW labels of the protected PE, and looks up the PW label in
> this label space. The bypass tunnel serves as the pointer to this label space.
> > [6] This draft also introduces the concept of "context ID". A context ID is an
> IP address identifying a pair of <primary PE, protector X>.
> > It serves as the destination of transport tunnel. PWs carried by the tunnel
> will be redirected to the protector X during local repair. PWs to the same
> primary PE but protected by a different protector Y cannot be carried by this
> tunnel. Rather, they must be carried by a tunnel destined for context ID of
> <primary PE, protector Y>.
> > [7] A PLR may be any router in the network, including P or PE router. The
> draft assumes that it doesn't know or care about PW info.
> >
> > in the "co-located" model. It may be a P router in the "centralized" model.
> For the later case, the draft describes how to use the new LDP extensions for
> the protector to learn and assoicate primary PW and backup PW and install
> forwarding entries in the context label table.
> > [yshen] This draft does not rely on label space coordination. Rather, it is
> based on context label forwarding paradigm specified in RFC 5331.
> >
> >
> >      called a transport tunnel *in this document*". Or we can completely
> replace "transport tunnel" with just "tunnel".
> >
> > [yshen] No, these topologies are only examples for use by subsequent
> sections to describe the mechanisms. The mechanisms should equally work
> for other topologies as well.
> >
> >      This SHALL enable
> > [yshen] We could rephrase this and remove "divergent". All we want to say
> here is that there are two distinct sets of AC-PW-AC between the CEs.
> >
> > [yshen] Will rephrase it. All we want to say is that at a given time, the CE
> may send traffic over one AC and receive traffic over another AC.
> >
> > [yshen] routers (LSRs). Yes, they have no idea about PWs. This draft
> doesn't assume they know or care about PWs.
> >
> > [yshen] There is no layer violation. The PLR simply redirect traffic from the
> original tunnel to a bypass tunnel, by doing a top label swap, without
> touching, changing or knowing the PW label. Please take a close look at the
> text.
> >
[[Sasha]] Does this mean that the bypass tunnel MUST NOT use the link between the PLR and the protected PE?
If yes, then how can this be done by normal LDP? Or do you intend to use some parts of CR-LDP for this?
> > [yshen] Similar to existing IP/MPLS fast-reroute RFCs, this draft doesn't
> restrict local repair trigger to any specific failure detection mechanisms. Any
> mechanism will work.
> >
> > [yshen] In collocated model, the protector is a PE. In the centralized model,
> the protector may be an LSR , and it needs to participate in LDP PW signaling
> to understand PWs. See the related sections and LDP extensions in this draft.
> This centralized model is optional.
> >
> > [yshen] Again, in collocated model, the protector is a PE. In the centralized
> model, the protector may be an LSR , and it needs to participate in LDP PW
> signaling to understand PWs. See the related sections and LDP extensions in
> this draft. But this centralized model is optional.
> > [yshen] PLRs may be LSRs, but they don't need to know PWs, because all
> they do is to swap top label (tunnel label) to a bypass tunnel's label.
> >
> > [yshen] PWs to a given PE may be protected by multiple protectors. A set
> of PWs sharing the same protector X can be carried by the same tunnel
> (destined to the context ID of <primary PE, X>). PWs protected by a different
> protector Y must be carried by different tunnel (destined to the context ID of
> <primary PE, Y>). The PLR of each tunnel doesn't need to know PW info. All it
> does is to swap tunnel label to a bypass tunnel's label, and the bypass tunnel
> will guide the traffic to the intended protector.
> >
> > [yshen] Again, in collocated model, the protector is a PE. In the centralized
> model, the protector may be an LSR , and it needs to participate in LDP PW
> signaling to understand PWs. See the related sections and LDP extensions in
> this draft. But this centralized model is optional.
> >
> >
> > [yshen] The protector will perform context label forwarding. The bypass
> tunnel points to a context label table, and the protector looks up the PW
> label in that table.
> >
> >      The protector MUST
> > [yshen] a context identifier is an IP address. If the tunnel is IP tunnel, it is
> carried in IP header as dest address. If the tunnel is MPLS tunnel, it is
> indicated by the label.
> >
> > [yshen] This is basically the context label forwarding paradigm (RFC 5331).
> From the protector's perspective, the bypass tunnel serves as a context, and
> indicates the label space of the primary PE where the PW label must be
> looked up.
> >
> >
> > [yshen] It mandates PHP for bypass tunnels only, as their labels serve as
> contexts on protectors. This is not mandatory for normal tunnels.
> >
> >
> >
> >
> > [yshen] The Protection FEC Element TLV carries the context ID of {primary
> PE, protector}. The {primary PE, protector} tuple itself is not encoded.
> >

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 05 Aug 2014 14:38:06 +0100

> And according to RFC 5331 per-platform label space is a special case of the label context.
However RRC5331 does not update RFC4447, so it must be
assumed that the original definition of per-platform
label space applies to PWs.

- Stewart

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 5 Aug 2014 13:59:49 +0000

Stewart,
I fully agree with you that using PW labels from a  label space that is not a per-platform one requires an explicit update to RFC 4447.
My comment on this point has been triggered by your saying that you *think* that RFC 4447 explicitly requires per-platform label space.
Just wanted to clarify that this is indeed the case.

Regards,
       Sasha 

> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Tuesday, August 05, 2014 4:38 PM
> To: Alexander Vainshtein; Yimin Shen
> Cc: [email-masked]; pwe3; [email-masked]
> Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-
> protection-01 - RFC4447
> 
> 
> >> architecture. It is also based on RFC 5331 " MPLS Upstream Label
> >> Assignment and Context-Specific Label Space". So ideally readers
> >> should be familiar with that RFC.
> >> As far as I can see context labels have not been introduced into the
> >> PWE3 architecture. There is some reference to their use for P2MP PWs,
> >> but not in the P2P case. Indeed I think that RFC4447 notes explicitly
> >> that in the case where the configuration of PWs is signaled by LDP
> >> the platform label space must be used. The least that you need to do
> >> is to update RFC4447.
> >>
> However RRC5331 does not update RFC4447, so it must be assumed that the
> original definition of per-platform label space applies to PWs.
> 
> - Stewart
>

---

From: Yimin Shen <[email-masked]>
Date: Tue, 5 Aug 2014 14:53:49 +0000

Hi Stewart, Sasha,

Every PE allocates PW labels from per-platform label space. This draft doesn't change this. In addition, a protector maintains a separate label table for each primary/protected PE that it protects. This label table contains the PW labels allocated by the primary/protected PE from its own "per-platform" label space. Hope this clarifies it.

Thanks,

/Yimin

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Tuesday, August 05, 2014 10:00 AM
To: [email-masked]
Cc: [email-masked]; pwe3; [email-masked]; Yimin Shen
Subject: RE: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447

Stewart,

Regards,
       Sasha

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 05 Aug 2014 17:12:19 +0100

> Every PE allocates PW labels from per-platform label space. This draft doesn't change this. In addition, a protector maintains a separate label table for each primary/protected PE that it protects.…
This all needs to be much clearer in the draft.

The protector in this context is I assume the receiving PE, not the 
protecting PE?

S

---

From: Eric Rosen <[email-masked]>
Date: Wed, 06 Aug 2014 11:54:19 -0400

I've looked at this draft, and it seems to me that it does work in LDP-based
networks (even with DU mode), and that it does not violate any architectural
principles.  However, I have made certain assumptions that aren't explicitly
stated in the draft.  (I am assuming that the draft is intended to be
patterned after the "anycast BGP" scheme that I've heard about about, but
that is not written up anywhere as far as I know.)  Let me say how I think
it is intended to work, and the authors can correct me if I'm wrong.

For protection against the failure of the "primary" egress PE:

- A "primary egress PE" partitions its set of PWs into n sets, where each
  set is associated with a given "protector".  The "protector" is the backup
  egress PE for those PWs.

- Each such set is associated with an IP address.  This IP address must be
  known both to the primary PE and to the protector.

  * One can think of this address as an "anycast" address that, to routing,
    denotes both the primary PE and the protector.  At the primary PE and
    the protector, the address denotes a particular set of PWs.

  * These anycast addresses are distributed by routing, and good old
    fashioned MPLS labels get assigned to them by LDP.  The primary PE MAY
    bind implicit null to that address, but the protector MUST NOT bind
    implicit null to that address.

  * Routing is set up so that (a) if the primary PE is up, traffic to the
    anycast address always goes to the primary PE, but (b) if the primary PE
    is down, traffic to the anycast address goes to the protector instead.
    This can be achieved by messing with the metrics, e.g.

- For a given PW, the primary PE informs both the protector and the ingress
  PE  of (a) the label that it (the primary PE) has assigned to that PW, and
  the "anycast address" that corresponds to that PW.  

  This requires some new signaling (beyond that specified in RFC 4447), but
  the requisite signaling is specified in the draft.

- When sending a packet on the given PW, the ingress PE pushes on the label
  assigned to the PW by the egress PE.  Then the ingress PE pushes on
  whatever LDP-assigned label it need to use to get the packet to the
  anycast address that is associated with the PW.

- When the protector learns that the egress PE has assigned a given label
  and anycast address to the PW, it stores that label in a context-specific
  label space associated with that anycast address.  Whenever the protector
  receives a packet whose top label is the label that the protector has
  bound to the given anycast address, the protector looks up the next label
  in the corresponding label space.  

Let's look at an example:

CE1---PE1----PLR----PE2----CE2
               |             |
               |-----PE3-----|

where PE3 is the protector for a PW connecting CE1 to CE2 (via PE1 and PE2
respectively).   Call this pseudowire PW1.

Thus there is some IP address, call it A, that PE2 and PE3 both advertise to
routing.  The metrics are set up so that as long as PE2 is up, it appears to
be a better path to A than does PE3.

So PE2 assigns label L1 to PW1, and uses T-LDP to inform both PE1 and PE3 of
this mapping.  To PE1, these are just outgoing labels.  To PE3, however,
they are incoming labels in a context-specific label space.

PE2 and PE3 both assign labels to A (let's call these labels L2 and L3
respectively), and distribute the corresponding label bindings to PLR.  PLR
also assigns a label to A, and distributes that label binding (L4) to PE1.

When PE1 has a packet to send on PW1, it pushes L1, then pushes L4, then
sends the packet to PLR.  PLR swaps L4 with L2 and sends the packet to PE2.
(Note that L2 could be implicit NULL.)  PE2 sees label L1, and sends the
packet to CE2.

Now if PE2 goes down, things happen a bit differently.  When PLR gets a
packet with L4 on top, it swaps L4 with L3, and sends the packet to PE3.  (In
this case, of course, L3 cannot be implicit NULL.)

PE3 gets the packet, sees L3 on top, looks it up, and then says "L3 is a
context label, so I have to pop it and then look up the following label in
the L3-specific label table."  This context-specific label table contains
L1, which has been bound to the PW that leads to CE2.  So PE2 pops the label
and sends the packet to CE2.

I think that's basically it, and the necessary mechanisms do seem to be
described in the draft.  The draft doesn't actually use the notion of
"anycast address" explicitly, but I think the intention is that the "context
labels" are definitely bound to anycast addresses.  I hope the authors will
correct me if I'm wrong.

Although the above example shows a PLR that is a neighbor of both PE2 and
PE3, this isn't really necessary, one could easily construct an example
where PE2 and PE3 have no neighbors in common.

The example above doesn't rely on LDP DoD at all, and doesn't make use of
any RSVP-TE backup tunnels.

However, when protecting against the failure of the egress AC, packets would
go first to PE2 then to PE3.  This scenario is a bit different, in that:

- I think this scenario may require an RSVP-TE backup tunnel (on which PHP
  is not used) from PE2 to PE3.

- PE2 would have to signal PE3 to associate the given PW with the given
  backup tunnel.

- The label that PE3 assigns to that backup tunnel would identify the
  context in which the PW label is looked up.

This is perhaps more detail than is actually in the draft ;-) but if it is
an accurate description of the authors' intentions, the scheme seems to
work.

I don't think this modifies the MPLS architecture at all.  It is true that
the PE3 needs to maintain a context-specific label table that contains
labels assigned by PE2.  While one may say that that is a "coordinated label
space", it is no more than what is required by the nature of
"upstream-assigned labels".  I.e., if you can't support this level of
coordination, you just can't support upstream-assigned labels.

Also, I don't think this draft is an "update" to RFC 4447.  You don't need
to read this draft to implement RFC 4447, nor does it modify the procedures
of RFC 4447.  It just introduces some new optional signaling and procedures.
I don't think RFC 4447's requirement to use the "platform label space"
should be interpreted as prohibiting the use of upstream-assigned labels.
The intention of RFC 4447 was to prohibit the use of the interface-specific
label space for PW labels.  This prohibition was necessary because the
ingress PE doesn't know which of the egress PE's network-facing interfaces
will actually receive a given packet.  This draft doesn't have that problem,
as it provides clear procedures for determining the context in which the
upstream-assigned labels are looked up.

---

From: Yimin Shen <[email-masked]>
Date: Wed, 6 Aug 2014 16:58:24 +0000

Hi Eric,

Thanks very much for your review and comments!

What you have described below is very accurate and indeed what this draft is basically about -- [1] Primary PE tells protector about PW labels; [2] Protector stores the PW labels in a special place called context label table, and knows when to look up label in this table; [3] PLR sets up a bypass tunnel to protector, and the bypass tunnel (UHP) serves as a hint (i.e. context) for protector to look up PW label in the context label table.

These 3 pieces are glued together by context ID and RFC 5331. Only for [1] the draft needs to define some LDP extensions. [2] is based on RFC 5331. [3] relies on existing IP/MPLS signaling and distribution protocols which are sufficient, and there doesn't seem to be any difficulty that tunnels and bypass tunnels cannot be set up in a scalable way.

Regarding why this draft calls the IP address as context ID rather than "anycast address", the main reason is that we wanted to emphasize its role of "context" in context label switching, from forwarding's point of view. A context ID is owned by both primary PE and protector. When it is advertised by both routers via IGP/BGP, yes, it could be viewed as an anycast address in terms of reachability.

Thanks,

/Yimin

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Eric Rosen
Sent: Wednesday, August 06, 2014 11:54 AM
To: Alexander Vainshtein
Cc: [email-masked]; pwe3; [email-masked]
Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447

I've looked at this draft, and it seems to me that it does work in LDP-based networks (even with DU mode), and that it does not violate any architectural principles.  However, I have made certain assumptions that aren't explicitly stated in the draft.  (I am assuming that the draft is intended to be patterned after the "anycast BGP" scheme that I've heard about about, but that is not written up anywhere as far as I know.)  Let me say how I think it is intended to work, and the authors can correct me if I'm wrong.

Thus there is some IP address, call it A, that PE2 and PE3 both advertise to routing.  The metrics are set up so that as long as PE2 is up, it appears to be a better path to A than does PE3.

So PE2 assigns label L1 to PW1, and uses T-LDP to inform both PE1 and PE3 of this mapping.  To PE1, these are just outgoing labels.  To PE3, however, they are incoming labels in a context-specific label space.

PE2 and PE3 both assign labels to A (let's call these labels L2 and L3 respectively), and distribute the corresponding label bindings to PLR.  PLR also assigns a label to A, and distributes that label binding (L4) to PE1.

When PE1 has a packet to send on PW1, it pushes L1, then pushes L4, then sends the packet to PLR.  PLR swaps L4 with L2 and sends the packet to PE2.
(Note that L2 could be implicit NULL.)  PE2 sees label L1, and sends the packet to CE2.

Now if PE2 goes down, things happen a bit differently.  When PLR gets a packet with L4 on top, it swaps L4 with L3, and sends the packet to PE3.  (In this case, of course, L3 cannot be implicit NULL.)

PE3 gets the packet, sees L3 on top, looks it up, and then says "L3 is a context label, so I have to pop it and then look up the following label in the L3-specific label table."  This context-specific label table contains L1, which has been bound to the PW that leads to CE2.  So PE2 pops the label and sends the packet to CE2.

I think that's basically it, and the necessary mechanisms do seem to be described in the draft.  The draft doesn't actually use the notion of "anycast address" explicitly, but I think the intention is that the "context labels" are definitely bound to anycast addresses.  I hope the authors will correct me if I'm wrong.

Although the above example shows a PLR that is a neighbor of both PE2 and PE3, this isn't really necessary, one could easily construct an example where PE2 and PE3 have no neighbors in common.

The example above doesn't rely on LDP DoD at all, and doesn't make use of any RSVP-TE backup tunnels.

However, when protecting against the failure of the egress AC, packets would go first to PE2 then to PE3.  This scenario is a bit different, in that:

This is perhaps more detail than is actually in the draft ;-) but if it is an accurate description of the authors' intentions, the scheme seems to work.

I don't think this modifies the MPLS architecture at all.  It is true that the PE3 needs to maintain a context-specific label table that contains labels assigned by PE2.  While one may say that that is a "coordinated label space", it is no more than what is required by the nature of "upstream-assigned labels".  I.e., if you can't support this level of coordination, you just can't support upstream-assigned labels.

Also, I don't think this draft is an "update" to RFC 4447.  You don't need to read this draft to implement RFC 4447, nor does it modify the procedures of RFC 4447.  It just introduces some new optional signaling and procedures.
I don't think RFC 4447's requirement to use the "platform label space"
should be interpreted as prohibiting the use of upstream-assigned labels.
The intention of RFC 4447 was to prohibit the use of the interface-specific label space for PW labels.  This prohibition was necessary because the ingress PE doesn't know which of the egress PE's network-facing interfaces will actually receive a given packet.  This draft doesn't have that problem, as it provides clear procedures for determining the context in which the upstream-assigned labels are looked up.

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Mingui Zhang <[email-masked]>
Date: Thu, 7 Aug 2014 03:56:57 +0000

Hi Eric, 

The explanation of the story is very clear. Let me complement a bit.

>  set is associated with a given "protector".  The "protector" is the backup

When the backup PE acts as the protector, it is the 'co-located' model. According to the text in the draft, the protector can also be any other PEs or Ps. That is the 'centralized' model. In this model, operators are allowed to designate the protector. Authors can correct me if I am wrong.

>an accurate description of the authors' intentions, the scheme seems to

I think the failure of the egress AC can't be handled as normal because the failure does not break the anycast IP address. Since this IP address used to be set to the loopback IP address of the PE. We know it's alive even those physical interfaces are broken. So I understand why you advise to handle the AC failures separately using the RSVP-TE backup tunnel.

I think we still have the chance to incorporate it into the single LDP based scheme:

We can replace the anycast IP address with an IP address of a virtual router. A link between the primary PE and the virtual router will appear in the routing. When the primary PE detect the AC failure. It acts as the PLR. It just translates it into a link failure of the routing and starts to use the backup tunnel that is prepared in advance for the link failure.

One concern is that "do we have scalability issue with these backup tunnels"? IOW, do we have to set up backup tunnels per AC? The answer is no. Actually, a set of ACs can multiplex the same backup tunnel if their corresponding CEs are multi-homed to the same pair of <primary PE, backup PE>.

Thanks,
Mingui

>From: pwe3 [mailto:[email-masked]] On Behalf Of Eric Rosen
>Sent: Wednesday, August 06, 2014 11:54 PM
>To: Alexander Vainshtein
>Cc: [email-masked]; pwe3; [email-masked]; [email-masked]
>Subject: Re: [PWE3] [mpls] WG Last Call for
>draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447
>

---

From: "Stewart Bryant (stbryant)" <[email-masked]>
Date: Thu, 7 Aug 2014 07:26:56 +0000

Sent from my iPad

> On 7 Aug 2014, at 04:57, "Mingui Zhang" <[email-masked]> wrote:
> 
> Hi Eric, 
> 
> When the backup PE acts as the protector, it is the 'co-located' model. 

This case does not however need context labels. It is a form of S-PE and can stitch the PWs just like every existing S-PE already does.

Stewart

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 7 Aug 2014 13:52:26 +0000

Eric,
Lots of thanks for a very detailed and clear response. It is by far more readable (from my point of view) than the original text in the draft. It has really helped me to understand the intention of the authors and some new potential pitfalls with this draft.

I agree with most of your comments about fundamental differences between protection against the failure of the Primary PE and protection against the "egress AC failure".  

I have some LDP-related questions that stem directly from your responses (I have added Loa to this thread). You have explained (and the draft also says that!) that the "context identifier" IP addresses must be known to both the primary PE and the Protector, LDP assigning labels for them and distributing corresponding Label Mappings.

1. I assume that this means that both the Primary PE and the Protector "own" this IP address, and, as a consequence, include it in the LDP Address messages they send to their respective adjacencies. Is this correct? 
2. If the answer to the previous question is "Yes", what is supposed to happen if the Primary PE and the Protector have a common adjacent P router?
    (This would be the case shown in Figure 5 in the draft if P3 were physically connected both to PE2 and PE4).
     Such a router would see the same IP address in the LDP Address messages received from two different adjacencies.
     Can LDP handle such a situation? Is it covered by RFC 5036?
3. If the answer for to my first question is "No", what would cause LDP in the Primary PE and the Protector to allocate a terminated label (i.e., 
     a label with action "Pop" in the ILM) to the FEC represented by the context identifier IP address? And how would the PLR understand that it is the penultimate hop towards the Primary PE?
     
I also have some doubts regarding ability to tweak the metrics in the network in such a way that, as you've explained:
-  As long as the Primary PE is up, the PLR sees it as the best Next Hop for the "context identifier" IP address
- Once the Primary PE is Down, the PLR sees the Protector as best Next Hop for the "context identifier" IP address.

These doubts are based on the following concerns:

1. Potential impact of ECMP. 
    ===================
    Suppose that ECMP is employed in the network, and that, as a consequence, there are multiple penultimate Next Hops 
    On multiple equal cost LSPs between PE1 and the Primary PE2. Is it possible by just playing with the metrics to guarantee that:
    - As long as the Primary PE2 is Up, each potential PLR would see it as the best next Hop towards the "context identifier"
    - Once PE2 is Down, each potential PLR (which would only know that its own link to the Primary PE has failed ) would treat the Protector as its best Next Hop
     towards the "context identifier"?

2. Potential impact of changes in the network topology. 
    ========================================
    Suppose that the metrics have been initially tweaked as required. Then some links between the
    PLR and the Protector fail so that the cost of the available path between them increases. Now, when the Primary PE goes Down, the PLR only sees that
    Its link to the Primary PE goes down, but the cost of some alternative path towards the "context identifier" could now still lead to the Primary PE. 

Due to these concerns, my personal bottom line is that operating the proposed mechanism over an MPLS network with LSPs instantiated using LDP in DU mode is sometimes possible but always tricky.  

Regards, and,again, lots of thanks,
       Sasha 

> From: Eric Rosen [mailto:[email-masked]]
> Sent: Wednesday, August 06, 2014 6:54 PM
> To: Alexander Vainshtein
> Cc: [email-masked]; [email-masked]; pwe3; [email-masked]
> stated in the draft.  (I am assuming that the draft is intended to be patterned
> after the "anycast BGP" scheme that I've heard about about, but that is not
> written up anywhere as far as I know.)  Let me say how I think it is intended
> to work, and the authors can correct me if I'm wrong.
> 
> routing.  The metrics are set up so that as long as PE2 is up, it appears to be a
> better path to A than does PE3.
> 
> this mapping.  To PE1, these are just outgoing labels.  To PE3, however, they
> are incoming labels in a context-specific label space.
> 
> PE3 gets the packet, sees L3 on top, looks it up, and then says "L3 is a context
> label, so I have to pop it and then look up the following label in the L3-specific
> label table."  This context-specific label table contains L1, which has been
> bound to the PW that leads to CE2.  So PE2 pops the label and sends the
> packet to CE2.
> 
> described in the draft.  The draft doesn't actually use the notion of "anycast
> address" explicitly, but I think the intention is that the "context labels" are
> definitely bound to anycast addresses.  I hope the authors will correct me if
> I'm wrong.
> 
> PE3, this isn't really necessary, one could easily construct an example where
> PE2 and PE3 have no neighbors in common.
> 
> However, when protecting against the failure of the egress AC, packets
> would go first to PE2 then to PE3.  This scenario is a bit different, in that:
> 
> This is perhaps more detail than is actually in the draft ;-) but if it is an
> accurate description of the authors' intentions, the scheme seems to work.
> 
> I don't think this modifies the MPLS architecture at all.  It is true that the PE3
> needs to maintain a context-specific label table that contains labels assigned
> by PE2.  While one may say that that is a "coordinated label space", it is no
> more than what is required by the nature of "upstream-assigned labels".
> I.e., if you can't support this level of coordination, you just can't support
> upstream-assigned labels.
> 
> Also, I don't think this draft is an "update" to RFC 4447.  You don't need to
> read this draft to implement RFC 4447, nor does it modify the procedures of
> RFC 4447.  It just introduces some new optional signaling and procedures.
> label space for PW labels.  This prohibition was necessary because the ingress
> PE doesn't know which of the egress PE's network-facing interfaces will
> actually receive a given packet.  This draft doesn't have that problem, as it
> provides clear procedures for determining the context in which the

---

From: Yimin Shen <[email-masked]>
Date: Thu, 7 Aug 2014 15:01:51 +0000

Hi Stewart,

Thanks very much again for the review and detailed comments.

We will consider your suggestions on the LDP TLV structures defined in this draft.

Regarding the tradeoff between the need for egress PE node protection and the increased state and complexity in PSN, this is a common considration for all IP/MPLS node protection, not PWE3 specific. We do see the requirement from service providers. I think this should be their decision on a per network basis. When they decide to do it, we have a solution available for them.

That said, this draft doesn't necessarily multiply the number of PSN tunnels. It does require one tunnel per <primary PE, protector>. However, if each primary PE is protected by only 1 protector, the number of tunnel will be the number of primary PEs, which is basically the same as the case where this mechanism is not used. This 1:1 relationship is achievable with the co-located model, and is especially achievable with the centralized model. Of course, in a more general case, if the avarage PE-to-protector ratio is 1:N, the number of tunnels will be multiplied by N. But operators can always design their networks thoughtfully and manage this N to be lowever than the threshold that may lead to scalability problems. (Here, I'm not counting bypass tunnels in, because bypass tunnels exist in the existing IP/MPLS fast-reroute as well.)

Thanks,

/Yimin

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Tuesday, August 05, 2014 6:56 AM
To: Yimin Shen; pwe3; [email-masked]
Cc: [email-masked]
Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01

Yimin,

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 07 Aug 2014 16:43:36 +0100

On 07/08/2014 16:01, Yimin Shen wrote:
> Regarding the tradeoff between the need for egress PE node protection and the increased state and complexity in PSN, this is a common considration for all IP/MPLS node protection, not PWE3 specific.
SB> Agree
> We do see the requirement from service providers. I think this should be their decision on a per network basis. When they decide to do it, we have a solution available for them.
SB> Sure but what is the view of the WG. Do we want to recommend this 
approach as the best approach to the industry, or should we recommend a 
simpler approach that allows better layer separation. Perhaps some 
operators could comment on what their requirements are so we can better 
a better feel for how to make the complexity+scale trade off against 
protection coverage.

SB> Remember a standards track RFC is a serious recommendation of good 
practice.

>
> That said, this draft doesn't necessarily multiply the number of PSN tunnels. It does require one tunnel per <primary PE, protector>.
SB> Surely it requires on per protection group?

> However, if each primary PE is protected by only 1 protector, the number of tunnel will be the number of primary PEs, which is basically the same as the case where this mechanism is not used.
SB> Not necessarily. This is a consequence of your method. Without 
context labels you deliver the traffic on the ordinary IP path to the 
alternative T-PE
> This 1:1 relationship is achievable with the co-located model, and is especially achievable with the centralized model. Of course, in a more general case, if the avarage PE-to-protector ratio is 1:N, the number of tunnels will be multiplied by N.
SB> With the centralized model - is this a PSN function, or is the 
centralized protector a type of S-PE?

> But operators can always design their networks thoughtfully and manage this N to be lowever than the threshold that may lead to scalability problems. (Here, I'm not counting bypass tunnels in, because bypass tunnels exist in the existing IP/MPLS fast-reroute as well.)
SB>Yes, but with some sort PW stitching model this simply does not apply.

- Stewart

---

From: Mingui Zhang <[email-masked]>
Date: Fri, 8 Aug 2014 02:46:44 +0000

Hi Stewart,

I think authors would say the S-PE stitching method involves the control plane processing during the repair procedure. They emphasized their method uses data plane & local repair, which can be faster.
Here, I want to raise one issue: 

If the primary PE fails and the PLR redirects the traffic during the flying of the packets, hoping the backup PE delivers the packets immediately. This means the AC at the backup PE side is also ACTIVE. So the CE has active-active connections to both egress PEs. This is obviously different from the PW-RED's active-standby mechanism [RFC6718]. Will this difference bring us the frame duplication issue? I think we need to address this in the updated version. 

Thanks,
Mingui

>From: Stewart Bryant (stbryant) [mailto:[email-masked]]
>Sent: Thursday, August 07, 2014 3:27 PM
>To: Mingui Zhang
>Cc: Eric Rosen (erosen); Alexander Vainshtein; [email-masked]; pwe3;
>[email-masked]
>This case does not however need context labels. It is a form of S-PE and can
>stitch the PWs just like every existing S-PE already does.
>
>Stewart
>

---

From: Loa Andersson <[email-masked]>
Date: Fri, 08 Aug 2014 11:31:00 +0200

Authors, Mingui, Stewart

> Here, I want to raise one issue:

It seems that we take it for granted that the method proposed on this
draft is faster than e.g. the e2e protection a la mpls-tp. Why is that?
If we have implementations of both, do we have any real measurements?

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 08 Aug 2014 10:54:21 +0100

On 08/08/2014 03:46, Mingui Zhang wrote:
> Hi Stewart,
>
> I think authors would say the S-PE stitching method involves the control plane processing during the repair procedure.
Then they would be incorrect.

The update of the PW entry in the FIB of an SPE is identical to the 
operation needed to update the FIB for any other FIB entry when FRR is 
triggered. Now there are more entries to update, but the degree of 
difficult presented will be implementation specific, but then so is the 
availability of context labels.
>   They emphasized their method uses data plane & local repair, which can be faster.
So would an FRR repair in the PW plane.

Stewart

---

From: Yimin Shen <[email-masked]>
Date: Fri, 8 Aug 2014 14:00:28 +0000

Hi Loa,

This draft assumes decoupled control plane and dataplane architecture of routers, and it requires that the backup path (or backup forwarding state) be pre-programmed in the dataplane on PLR. Hence when the dataplane (of PLR) detects a failure, it is able to restore traffic locally and independently by redirecting traffic over the preprogrammed backup path. This is generally assumed to be faster that mechanisms that involve control plane protocols, or end-to-end messaging or OAM, because there is no event propagation delay. I believe this is a common assumption for all IP/MPLS FRR mechanisms.

It will not be a problem if this mechanism and an e2e mechanism are both implemented in a network. As described in the draft, this mechanism provides local repair, and it is viewed as a temporary repair. The draft strongly recommend this mechanism to be used in tandem with an e2e or global repair mechanism, so that the later can eventually move traffic from the locally repaired PW over to a fully functional PW, as a permanent repair.

Thanks,

/Yimin

-----Original Message-----
From: pwe3 [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Friday, August 08, 2014 5:31 AM
To: Mingui Zhang; Stewart Bryant (stbryant)
Cc: [email-masked]; Eric Rosen (erosen); pwe3; [email-masked]
Subject: Re: [PWE3] [mpls] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447

Authors, Mingui, Stewart

> Here, I want to raise one issue:

It seems that we take it for granted that the method proposed on this draft is faster than e.g. the e2e protection a la mpls-tp. Why is that?
If we have implementations of both, do we have any real measurements?

/Loa

--

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 8 Aug 2014 07:02:46 -0700

Loa,

> > I think authors would say the S-PE stitching method involves 
> > the control plane processing during the repair procedure. They 
> > emphasized their method uses data plane & local repair, which 
> > can be faster.

To answer your question let me quote from "Network Recovery" by JP
Vasseur, Mario Pickavet, Piet Demeester (Section 5.8.1, page 336):

  With global protection, rerouting is performed by the head-end
  LSR, which means that this requires for the head-end LSR to receive
  the failure indication to reroute the affected traffic onto their
  respective backup paths (whose paths have been precomputed and
  signaled). So in terms of recovery time, the delta between global
  and local protection is the failure indication signal propagation
  time to the head-end LSR.

Yakov.

---

From: Loa Andersson <[email-masked]>
Date: Fri, 08 Aug 2014 16:40:46 +0200

Yakov,

>    time to the head-end LSR.

Well, I won't argue that this is what is said in the book, but it is
not what I asked about.

mpls-tp runs e.g. 1:1 or 1:n, i.e. 1 working lsp (or pw) is protected
by one or more pre-established  lsp's or pw's. detection time can be
as low as 10ms and the switch over is far shorter.

While I understand that the draft is much more resource conservative,
what is the foundation to claim that is faster?

/Loa

--

---

From: Yimin Shen <[email-masked]>
Date: Fri, 8 Aug 2014 15:37:24 +0000

Hi Mingui,

Thanks for the comments. Please see inline...

Thanks,

/Yimin

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Mingui Zhang
Sent: Thursday, August 07, 2014 10:47 PM
To: Stewart Bryant (stbryant)
Cc: [email-masked]; pwe3; [email-masked]
Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447

Hi Stewart,

[yshen] Don't confuse the backup PW in this document with the standby PW in RFC 6718. Each active or standby PW in RFC 6718 could be protected by a backup PW specified in this draft, if that's intended. There shouldn't be any packet duplication during local repair, because PLR only sends packets to protector.

Thanks,
Mingui

>>> - A "primary egress PE" partitions its set of PWs into n sets, where 
>>> each set is associated with a given "protector".  The "protector" is 
>>> the backup egress PE for those PWs.
>>
>This case does not however need context labels. It is a form of S-PE 
>and can stitch the PWs just like every existing S-PE already does.
>
>Stewart
>

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 8 Aug 2014 12:27:33 -0700

Loa,

> what is the foundation to claim that is faster?

Local protection does not involve propagating failure indication
beyond the point of failure.

Do you think that the detection time at the head-end can be less
than the time it takes to propagate failure indication from the
point of failure to the head-end ?

Furhermore, even if we assume that for some topologies the propagation
time could be 10ms, could it be 10ms irrespective of the distance
and the number of hops spanned by a PW ?

Yakov.

---

From: Loa Andersson <[email-masked]>
Date: Sat, 09 Aug 2014 13:22:14 +0200

Yakov,

> and the number of hops spanned by a PW ?

MPLS-TP style protection does not involve propagating (i.e. does not
involve sending a a failure indication from the point of detection to
the head end). The failure at the head end is e.g. detected if you
loose three consecutive keep alive message traveling in the data plane.

If you send one keep-alive message every 3.3 msec, you can reach a
time to repair this is
- detection time (approximately 10 ms)
- transfer time (typically usec's)
- switchover time (good guess is approximately 10 ms)

MPLS-TP protection was designed to met the 50 msec requirement, it is my
guess that is about the same as what this draft achieves.

Note that I'm not say that the protection mechanism described is "bad"
or "slow", to the contrary I think it is both useful and fast, only that
we are talking of time to repair for the to mechanisms.

/Loa

--

---

From: Huub van Helvoort <[email-masked]>
Date: Sat, 09 Aug 2014 13:40:40 +0200

Hello Yimin,

You wrote:

 > It will not be a problem if this mechanism and an e2e mechanism
 > are both implemented in a network. As described in the draft,
 > this mechanism provides local repair, and it is viewed as a
 > temporary repair. The draft strongly recommend this mechanism
 > to be used in tandem with an e2e or global repair mechanism,
 > so that the later can eventually move traffic from the locally
 > repaired PW over to a fully functional PW, as a permanent repair.

How do you warrant that all the repair mechanisms present do
not decide to switch at the same time?
This would result in unpredictable repairs.
So some coordination between the repair mechanisms is required.

regards, Huub.

-- 
*****************************************************************
               请记住，你是独一无二的，就像其他每一个人一样