Subject: [Gen-art] Gen-ART review of draft-ietf-mpls-lsp-ping-10.txt

From: [email-masked]
Date: Fri, 21 Oct 2005 18:08:12 -0400

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-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art