Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Networks Using Entropy Labels (ELs)
draft-ietf-mpls-entropy-lsp-ping-05
Yes
No Objection
(Alissa Cooper)
(Ben Campbell)
(Joel Jaeggli)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)
Note: This ballot was opened for revision 04 and is now closed.
Deborah Brungard Former IESG member
Yes
Yes
(2016-08-26 for -04)
Unknown
As noted on the list discussion, the chairs, authors, and I discussed "what is an update": https://mailarchive.ietf.org/arch/msg/mpls/c1lVXUC6xruy0hvl5i5GzSKUVwE We concluded the document only really updates RFC6790 as the update isn't mandatory for the "general" lsp-ping RFCs to implement. The authors will correct this on their next respin.
Alissa Cooper Former IESG member
No Objection
No Objection
(for -04)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(2016-08-31 for -04)
Unknown
Just a nit: It would be nice to move Section 10 towards the front of the document. I know there are a couple of references to it, but knowing upfront the scope would be helpful to any reader.
Ben Campbell Former IESG member
No Objection
No Objection
(for -04)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(2016-08-31 for -04)
Unknown
As noted by Scott Bradner in his OPS DIR review, 2 issues worth addressing IMO. I did an OPS-DIR review of Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Network using Entropy Labels (EL) (draft-ietf-mpls-entropy-lsp-ping-04) The draft extends the existing MPLS LSP Ping and Traceroute multipath mechanisms to support LSPs that use an Entropy Label. The primary operational impact of this technology is to provide an additional tool for network operators to debug their networks - a good thing. I found the draft a bit hard to follow, it seems to be more a collection of data points than a clear narrative but I do not think it is worth a rewrite to make it easier to understand. I found one thing that raises an operational concern - the next to last paragraph in section 2 says: “All LSRs along the LSP need to be able to understand the new flags and the new multipath information type.” But I do not see a mechanism discussed to check to see if that is the case (like the high order two bits of IPv6 options). If there is a mechanism it might be good to describe it, if there is not, a statement that verifying this condition is outside of the scope of the draft would be helpful The same paragraph goes on to say “It is also required that the initiating LSR can select both the IP destination address and label to use when transmitting MPLS echo request packets.” It might be helpful to say under what conditions this is or is not the case. Otherwise, the draft seems ready for publication.
Jari Arkko Former IESG member
No Objection
No Objection
(2016-08-30 for -04)
Unknown
Editorial observations from Peter (in his Gen-ART review) are worth noting before final sending of this draft to the RFC Editor.
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -04)
Unknown
Kathleen Moriarty Former IESG member
(was Discuss)
No Objection
No Objection
(2016-09-01 for -04)
Unknown
Thank you for the updated text in your draft version to address my prior discuss questions.
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2016-08-31 for -04)
Unknown
As Scott mentioned in his review, I also think that the following sentence needs more discussion: "All LSRs along the LSP need to be able to understand the new flags and the new multipath information type." How can you ever know if this is true? Isn't the whole problem that you don't know what different LSRs implement?
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -04)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2016-09-01 for -04)
Unknown
Just to note that there's an editorial change that was agreed [1] as a result of the secdir review that has still to be made. (No big deal, just noting it in case it gets forgotten.) [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06754.html
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -04)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -04)
Unknown