Background for those who may be unaware of GenART: GenART is the Area Review Team for the General Area of the IETF. We advise the General Area Director (i.e. the IETF/IESG chair) by providing more in depth reviews than he could do himself of documents that come up for final decision in IESG telechat. I was selected as the GenART member to review this document. Below is my review, which was written specifically with an eye to the GenART process, but since I believe that it will be useful to have these comments more widely distributed, others outside the GenART group are included.
Review criteria for WG submissions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" This draft is on the right track but has open issues, described in the 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. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [EMAIL PROTECTED] Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
