Explicit Path Routing for Dynamic Multi-Segment Pseudowires
draft-ietf-pwe3-mspw-er-06

Ok - sorry for the confusion.

Wondering if any of the mays and musts in Section 4.2 should be MAYs or MUSTs. I noted that in 4.1, the text says "Processing continues as per Section 4.2, where a new explicit route TLV MAY be added to the Label Mapping Message," but the behavior specified in 4.2 is not described normatively.

Looks ok from a security standpoint, interested to see the clearer language from Alia's review.

- I'm not sure to what extent this may be a significant
threat, but want to check. This new mechanism seems to create
a new way to attempt to DoS or probe a MS-PW if one is allowed
to send any traffic on that MS-PW as an S-PE (or a zombied
S-PE) - any such sender can nominate the path for traffic. Why
is that not a new security consideration? If it is, (and I
think it is), then at least noting that in the security
considerations section would seem right. And how might one
detect or otherwise mitigate such a nasty S-PE? 

- To be honest, I found 4.1 and 4.2 very hard to take in. I'd
suggest maybe a re-write but IFF others have had similar
difficulty. (If its just me, then ignore me.) Some examples
below.

- 2nd sentence of 4.1 - who is selecting when? (Passive
voice?)

- "MUST attempt" is very odd, is that the same as "MAY not
bother"? :-)

- "If a loop free path cannot be found..." by whom?

- "If the L bit is not set in the first ER Hop and if the node
is not part of the abstract node described by the first ER Hop
(i.e it does not lie within the prefix as determined by the
prefix length specified in the ER-Hop TLV), it has received
the message in error, and MUST reply with a Label Release
Message with a "Bad Initial ER Hop Error" (0x04000004) status
code." Does that *all* really have to be one and only one
sentence?

In 3.2:
   The ER-TLV specifies the path to be taken by the MS-PW being
   established.  Each hop along the path is represented by an abstract
   node, which is a group of one or more S-PEs, identified by an IPv4,
   and IPv6 or an S-PE address.  The ER-TLV format is as per Section 4.1
  ^^^^^
   of [RFC3212].

I think the "and" that I indicated should be an "an".   I mention this because although it's a fairly obvious typo, it _could_ actually be intentional, and hence doesn't qualify as strictly editorial.   If it is intentional, you should remove the preceding comma.

In 4.1:
   3.  If a second ER Hop TV does exist, and the node is also a part of

Again kind of nit-picky, but I think you mean TLV here, not TV.

FWIW (referring to Stephen's comment), I did not find section 4 difficult to follow.