Explicit Path Routing for Dynamic Multi-Segment Pseudowires
draft-ietf-pwe3-mspw-er-06
Yes
No Objection
(Barry Leiba)
(Benoît Claise)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Richard Barnes)
(Spencer Dawkins)
Note: This ballot was opened for revision 05 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
(2014-08-25 for -05)
Unknown
Need to pick up the nits from Meral's GenArt review > [Page 6], Section 4.1, typo: "A noted in Section 1"---->"As noted in Section 1" > > [Page 6],"but each node MUST attempt to determine a loop-free path", > if the only method to detect a loop is http://tools.ietf.org/html/rfc6073#section-7.6, > then perhaps a reference to this RFC would be useful. > [Page 8], Section 5, typo :"consesus"---->"consensus"
Alia Atlas Former IESG member
(was Discuss)
No Objection
No Objection
(2014-09-02 for -05)
Unknown
Ok - sorry for the confusion.
Alissa Cooper Former IESG member
No Objection
No Objection
(2014-09-01 for -05)
Unknown
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.
Barry Leiba Former IESG member
No Objection
No Objection
(for -05)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(for -05)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -05)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -05)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -05)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2014-08-29 for -05)
Unknown
Looks ok from a security standpoint, interested to see the clearer language from Alia's review.
Richard Barnes Former IESG member
No Objection
No Objection
(for -05)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -05)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2014-09-03 for -05)
Unknown
- 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?
Ted Lemon Former IESG member
No Objection
No Objection
(2014-09-04 for -05)
Unknown
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.