Pseudowire (PW) Endpoint Fast Failure Protection
draft-ietf-pals-endpoint-fast-protection-05

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

I support Suresh' Discuss.

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?

- 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.

Thanks for addressing my DISCUSS point in -05.