Experience with the Label Distribution Protocol (LDP)
Note: This ballot was opened for revision 00 and is now closed.
(Margaret Cullen) Discuss
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
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
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 126.96.36.199 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 188.8.131.52, 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
(Lars Eggert) No Objection
(Ted Hardie) No Objection
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
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?