Pseudowire (PW) Endpoint Fast Failure Protection
RFC 8104

Note: This ballot was opened for revision 04 and is now closed.

(Alia Atlas) Yes

Comment (2016-12-14 for -04)
No email
send info
Minor:

1) The details in Figure 11 on p. 22 don't look quite right.    There is no forwarding state shown on PE4 to handle the incoming labels of 2000 (P3's outgoing label of bypass tunnel to PE4) or 3000 (P2's outgoing label of bypass tunnel to PE4).    Either there should be additional forwarding state on PE4 that says to pop 2000 (or 3000) and identify a context label space - or PE4 should have allocated the context label 999 to the bypass tunnels from P3 and PE2.

I see the same issue in Figures 12, 13, and 14.   Is there  a detail or explanation missing?

Deborah Brungard Yes

(Jari Arkko) No Objection

Comment (2016-12-15 for -04)
No email
send info
I support Suresh' Discuss.

(Ben Campbell) No Objection

(Benoît Claise) No Objection

Comment (2016-12-15 for -04)
No email
send info
Editorial nits (From Sue Hares, part of her OPS-DIR review)

1.       Page 10  - style makes difficult reading of sentence  (very minor nit).

OLD /A PLR MUST Be able to detect a failure by using a rapid mechanism, such as physical layer failure detection, Bidirectional failure detection (BFD) [RFC5880], etc. /

NEW /A PLR MUST Be able to detect a failure by using a rapid mechanism, such as physical layer failure detection, Bidirectional failure detection (BFD) [RFC5880], and others/

2.       Page 32 – difficult to parse sentence

      Old/For Encoding type, 1 is defined for PWid FEC element format, and 2 is defined for the Generalized PWid FEC Element format [RFC4447]./

      New/ For type encoding type, the following two values are defined within this document:

-          Type 1 for PWid FEC element format (see section 6.4.1.), and

-          Type 2 for Generalized PWid FEC Element format [RFC4447

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2016-12-14 for -04)
No email
send info
- section 5: I'm not sure "revertive" is a useful term
here. Seems to me that it's a) admirably obscure, b) maybe
inaccurate, as we're not reverting to a previous state
here but rather changing paths, and maybe c) it's not
clear if we end up with a "fully functional" path after
"reverting." But maybe it's an accepted term of art in
routing - if so, some reference to where it's well
described might be nice.

- section 8, para 1: this assumes that "managed by network
operator" means "is secure." I think we have examples
where not all that happens within a network is under the
control of the owner of the network, so I question that
assumption. (I'm not now asking for a concrete change as
that'd be a major bit of work, but I am as willing as ever
to continue to call this out as it appears;-) If you could
remove text based on that assumption, that'd improve the
document I think.

(Joel Jaeggli) No Objection

(Suresh Krishnan) (was Discuss) No Objection

Comment (2017-01-05)
No email
send info
Thanks for addressing my DISCUSS point in -05.

(Mirja Kühlewind) No Objection

Comment (2016-12-14 for -04)
No email
send info
A few smallish comments/questions:

1) This is no news but there are a lot of acronyms in this drafts which makes it partly hard to read. Some of them are never spelled out, such as PE, CE, RSVP... I would like to propose two changes to support the reader: 1) Spell out all acronyms in the abstract and 2) add a glossary. Further you could maybe also define some terminology at the beginning such as 'protector'.

2) This sentence/use of acronym is confusing: 
"In Figure 1, the IP/MPLS network consists of PE and P routers."
NEW:
"In Figure 1, the IP/MPLS network consists of four PEs and two routers P1 and P2."

3) I don't fully understand this part in sec 4.1:
"Normally the router will attempt to
   forward PW packets in a load balance fashion over the ECMP set.  When
   the link fails, if the router reroutes only the portion of traffic
   originally traversing the link while letting the rest of traffic
   remain on the other ECMP branches, it will create a situation where
   the egress CE receives traffic from both the primary PE and the
   backup PE. "
If you have two ECMP branches, why don't you simply use the other one for all traffic? Isn't this the kind of protection your are discussing? Or are you assuming that this note somewhere on the PW does not apply this backup strategy?

4) Do you have references for mechanisms described in section 5?

One high level comment:
I was wondering while reading the whole time if this should be informational or standards track. Was there any discussion in the wg? Are there implementations?

(Alexey Melnikov) No Objection

(Kathleen Moriarty) No Objection

Alvaro Retana No Objection