[Gen-art] GenART review of MPLS LDP drafts

[[e-mail]]

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.

This review was done as part of IETF Last Call.  I apologize for the
delay on this review, as Monday was a holiday in the US.

Review criteria: "Is this document a reasonable contribution to the
area of Internet engineering which it covers?  If not, what changes
would make it so?"

These drafts are on the right track but have open issues, described
in the review.

All of the significant new issues are IETF process issues.  There are
also a number of nits in the main LDP draft that need to be corrected,
and I found the security issue described in Sam Hartman's Discuss.

While Brian Carpenter has already voted No Objection on this draft, I
think a Discuss is in order to resolve the process issues.

--- draft-ietf-mpls-rfc3036bis-03.txt for Draft Standard

(1) This draft has a major process problem - Section 2.9 has a normative
dependency on the TCP MD5 signature option.  The maturity variance for
the TCP MD5 signature option in RFC 4278 is primarily for BGP - RFC 4278
has only this to say about LDP (Section 5):

   The Label Distribution Protocol (LDP) [RFC3036] also uses [RFC2385].
   Deployment practices for LDP are very similar to those of BGP: LDP
   connections are usually confined within a single autonomous system
   and most frequently span a single link between two routers.  This
   makes the LDP threat environment very similar to BGP's.  Given this,
   and a considerable installed base of LDP in service provider
   networks, we are not deprecating [RFC2385] for use with LDP.

While that text indicates the IESG's inclination to grant a maturity
variance for TCP MD5's usage in LDP, it does not actually grant the
variance.  The LDP draft attempts to sidestep this by making RFC 2385
a non-normative reference (Section 9.2).  That approach is clearly
wrong, as Section 2.9 says:

   This section specifies a mechanism to protect against the introduc-
   tion of spoofed TCP segments into LDP session connection streams.
   The use of this mechanism MUST be supported as a configurable option.

   The mechanism is based on use of the TCP MD5 Signature Option speci-
   fied in [RFC2385] for use by BGP.

The "MUST" in the quoted text requires that RFC 2385 be a normative
reference.  Hence, the IESG appears to need to grant an explicit standards
maturity variance for TCP MD5's use in LDP if Section 2.9 is to remain
in the LDP draft.  Granting that variance is probably the proverbial
"right thing" to do, but it does appear to be necessary to do so.

(2) Section 3.6.1.1 allows the U bit to be clear for a vendor-private
TLV, so that if the TLV is not understood, the entire message is
rejected.  This appears to allow mandatory vendor-private extensions,
which has been an IESG concern in the past.  If mandatory vendor-
private TLV elements are not to be allowed, this section would need
to require that the U bit always be set for a vendor-private TLV.  An
analogous issue occurs for the U bit in vendor-private messages in
Section 3.6.1.2, but could be addressed by requiring a sender to
continue if a vendor-private message is rejected.

(3) Sam Hartman's Discuss on Section 5.1 should be supported - an
explanation of why something is bad should generally be provided
when specifying mitigation measures for it.

Nits:

Section 2.5.3 uses the acronyms VPI, VCI and DLCI without
prior definition.  While I'm sure these acronyms are obvious
to MPLS experts, expansions should be provided.  Expansions
are provided later (Sections 3.4.2.2 and 3.4.2.3) and need
to be reproduced here.

Section 2.8.3 "should" in first line ought to be "SHOULD",
but I could be convinced otherwise as this is a requirement
on network administrators as opposed to protocol implementers.

A number of the TLVs are not aligned lengths (e.g., Hop Count
is an odd number of bytes - 5).  Section 3.3 implies that there
is no padding between TLVs, but it would be useful for Section
3.5 to say that there is no padding at the end of a message
(e.g., despite the diagram in Section 3.5, parameters can end
on odd-byte boundaries).

Section 5.3, subsection 2 contains a number of "should" statements
that probably ought to be changed to "SHOULD"s.

Section 6 uses the CoS acronym without prior definition or
expansion.

--- draft-ietf-mpls-ldp-experience-00.txt for Informational

This draft appears to be fine.

--- draft-ietf-mpls-ldp-survey2002-00.txt for Informational

(4) This draft also has a process issue that affects the main LDP draft.
Section 4.1.2 of RFC 2026 says the following about the interoperability
requirement for advancing to draft standard:

   The requirement for at least two independent and interoperable
   implementations applies to all of the options and features of the
   specification.  In cases in which one or more options or features
   have not been demonstrated in at least two interoperable
   implementations, the specification may advance to the Draft Standard
   level only if those options or features are removed.

Applying this criterion to the survey draft, Section 1.1 says:

     At By Cn indicates:

     - A responders implemented the feature and tested it against
       another independent implementation (t);

So, for a feature to remain at Draft Standard, A must be at least 2.
Unfortunately, there are three instances where A is 1:

        1t 1y 1n       IPv6 Transport Addr TLV
        1t 5y 6n       Experimental TLV
        1t 5y 6n       Experimental Msg

While I'm not concerned about the experimental value ranges - I
think those are good things to have and don't need to be subject
to the 2 interoperable implementations test, the IPv6 address
TLV looks like a potential problem:

    1t 1y 1n(1u 4r 1x)   IPv6 Transport Addr TLV    3.5.2

Unless another implementation can be found, it appears that RFC
2026 would require deleting IPv6 support in order to advance
to Draft Standard.  That would be unfortunate.

---------------------------------------

I wish I had real technical issues to report instead of this
IETF process <expletive-deleted>.

Sorry,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------

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