Experience with the Label Distribution Protocol (LDP)
RFC 5037

Note: This ballot was opened for revision 00 and is now closed.

(Margaret Cullen) Discuss

Discuss (2006-02-16)
I am having some trouble understanding how the implementation report shows that 2 independent implementations, both of which are included in this report, were tested together for each feature.

Are the raw results of the implementation reports (i.e. showing what was included in each implementation and what was tested against which other implementations) available anywhere?

(Bill Fenner) Yes

(Alex Zinin) Yes

(Jari Arkko) (was Discuss) No Objection

Comment (2007-03-19)
No email
send info
Bill Fenner has posted a new implementation survey in the form of
an e-mail that lists the results of an e-mail poll that the chairs
made. Its borderline whether this really qualifies as a good implementation
report, but I'm not sure I should hold a discuss any longer because
we weren't really missing the whole report, just the answer to the
question of whether it referred to 3036 or the bis document.

(Ross Callon) No Objection

(Brian Carpenter) No Objection

Comment (2006-03-06)
No email
send info
From Gen-ART review of draft-ietf-mpls-rfc3036bis-03.txt 
by David Black. These comments arrived after I already
entered No Objection but seem to need attention.

(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 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, but could be addressed by requiring a sender to
continue if a vendor-private message is rejected.

Also see
for nits

(Lars Eggert) No Objection

(Ted Hardie) No Objection

Comment (2006-02-16)
No email
send info
I strongly concur with Scott's concerns about the implementation report.  I am not holding a discuss because I believe they have been heard.

(Sam Hartman) (was Discuss) No Objection

(David Kessens) No Objection

(Allison Mankin) No Objection

(Jon Peterson) No Objection

(Mark Townsley) No Objection

(Scott Hollenbeck) Abstain

Comment (2006-02-13)
No email
send info
I'm abstaining for now because I won't be on the call this week and I won't be able to ask this question directly.  I'll consider moving to a no-ob if the answer is "yes".

The implementation report describes a survey conducted in 2002.  draft-ietf-mpls-rfc3036bis-03 is a candidate for Draft Standard.  Has 3036bis been around since 2002 such that the survey corresponds to the specification it documents?