Skip to main content

Experience with the Label Distribution Protocol (LDP)
draft-ietf-mpls-ldp-experience-00

Discuss


Yes

(Alex Zinin)
(Bill Fenner)

No Objection

(Allison Mankin)
(David Kessens)
(Jon Peterson)
(Lars Eggert)
(Mark Townsley)
(Ross Callon)
(Sam Hartman)

Abstain


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

Margaret Cullen Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2006-02-16) Unknown
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?
Alex Zinin Former IESG member
Yes
Yes () Unknown

                            
Bill Fenner Former IESG member
Yes
Yes () Unknown

                            
Allison Mankin Former IESG member
No Objection
No Objection () Unknown

                            
Brian Carpenter Former IESG member
No Objection
No Objection (2006-03-06) Unknown
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 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.

Also see
http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-mpls-rfc3036bis-03-black.txt
for nits
David Kessens Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
(was Discuss) No Objection
No Objection (2007-03-19) Unknown
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.
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Lars Eggert Former IESG member
No Objection
No Objection () Unknown

                            
Mark Townsley Former IESG member
No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Sam Hartman Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Ted Hardie Former IESG member
No Objection
No Objection (2006-02-16) Unknown
I strongly concur with Scott's concerns about the implementation report.  I am not holding a discuss because I believe they have been heard.
Scott Hollenbeck Former IESG member
Abstain
Abstain (2006-02-13) Unknown
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?