Document: draft-ietf-mpls-lsp-ping-10.txt Reviewer: Black_David@emc.com Re-Review Date: Monday 11/21/2005 11:35 AM CST Telechat Date: Thursday 12/01/2005 Summary: Ready with RFC Editor note. Review: ------- This draft has already been GenART reviewed (detailed review is below). Based on email discussion of that review with the draft authors, the conclusion was that an RFC Editor Note should be used to add a paragraph as follows: ....For the RFC Editor.... Section 1.1 Conventions [Add new paragraph at end] Since this document refers to the MPLS TTL far more frequently than the IP TTL, the authors have chosen the convention of using the unqualified "TTL" to mean "MPLS TTL" and using "IP TTL" for the TTL value in the IP header. .......................... Beyond this, the draft is in fine shape. Is it Alex's responsibility to insert the necessary RFC Editor Note in the ballot/announcement? -------------------------------------------------------------------------------- Original Review Date: Friday 10/21/2005 5:08 PM CST Telechat Date: Thursday 10/27/2005 Summary: This draft is on the right track but has open issues, described in the review. Review: ------- The draft is significantly improved from it's -09 (IETF Last Call) version, but still has an important open issue from the previous GenART review. The GenART review of the -09 version raised 2 issues: (1) The MPLS ping mechanism is rather complex by comparison to the IP ping mechanism. Guidance on effective and appropriate use of the available complexity would improve the draft. (2) The Security Considerations were unacceptable. This has been addressed by rewriting the Security Considerations section. Issue (1) has not been addressed in this version of the draft. I think an AD-level discussion about intended audience for this draft is in order - if this draft need only be accessible to an MPLS expert audience (primarily implementers), then ignoring Issue (1) is ok. OTOH, if the draft should be accessible to users of MPLS Ping (e.g., MPLS network administrators), Issue (1) should be addressed. I recommend that this discussion take place and that a "Discuss" be placed against this draft only if it is needed to cause or facilitate that discussion; such a "Discuss" should include a promise to withdraw it if the IESG concludes that MPLS experts are the only intended audience. Here is the Issue (1) text from the original review: (1) IP ping and traceroute are robust debugging tools because they are based on a simple underlying TTL mechanism, so that if a ping or traceroute packet goes off into a void, one can be reasonably confident that something in the data plane is broken close to where the packet vanished. MPLS ping/traceroute is considerably more complex (40+ page draft). That's not necessarily bad, as MPLS is a more complex entity and ping/traceroute for MPLS has to deal with a known weakness in IP ping/traceroute, namely that an IP TTL mechanism can't see what's going on inside a tunnel ... and MPLS is all about what are essentially tunnels. On balance, I think having a rich mechanism capable of probing the myriad ways in which MPLS could malfunction is highly desirable, but ... ... this complexity carries a risk of fragility - if an arbitrarily complex MPLS ping packet goes off into a void in the absence of other information, it's not as obvious that the data plane is broken (vs. the MPLS ping/traceroute logic being broken, or a mistake having been made in formatting the packet) in contrast to the IP case. OTOH, there are a number of fairly simple examples in the draft that lead me to believe that the richness of the MPLS mechanism can be used with complexity commensurate to the problem being investigated, and that one can start simple and gradually increase the complexity as ping/traceroute success/failure yields more information about where the problem is (and isn't). Section 4 on Theory of Operation contains some useful info, but it's mostly a complete specification of all the possible operational details at full depth. A complementary "advice on usage" and/or "examples of usage" section giving advice and/or examples of how to start with something simple and step up to more complex ping/traceroute probes as one learns more would be useful. This sort of discussion of how to organize pursuit of problems would be valuable to both implementers (indication of what basic portions of MPLS ping/traceroute really need to be robust) and operators (advice on effective usage of the functionality). I realize that I started by noticing the length of the draft, and am nonetheless asking for it to be longer, but I think this would help. I could envision this review being objected to on the grounds that the advice that is being asked for is essentially use of "common sense" - I would observe that in complex technical areas such as MPLS, "common sense" can be rather uncommon. The following Nit has also not been addressed: Nit: This draft uses "TTL" to refer the MPLS TTL and "IP TTL" to refer to the TTL in the IP header. That convention makes sense for an MPLS draft, but it should be stated in the conventions section, just in case the reader is not an MPLS expert. An RFC Editor Note should suffice for this Nit.