Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)
draft-ietf-mpls-ldp-typed-wildcard-07

[Ballot comment]
I am in favor of approving this document, but I would like to raise a clarification question origibated by the OPS-DIR review by Menachem Dodge. It is not a show-stopper, but it points to a possible inconsistency between this document and RFC 5036:


In Section 8: "IANA Considerations" the following is stated:
      "The 'Typed Wildcard FEC' Capability requires a code point from the TLV Type name space.  [RFC5036] partitions the TLV TYPE name space into 3 regions:  IETF Consensus region, First Come FirstServed region, and Private Use region.  The authors recommend that a code point from the IETF Consensus range be assigned to the 'Typed Wildcard FEC' Capability."

When checking RFC 5036 Section 4.2 "TLV Type Name Space" I find the following text:

  "LDP divides the name space for TLV types into three ranges.  The
following are the guidelines for managing these ranges:
-  TLV Types 0x0000 - 0x3DFF.  TLV types in this range are part of the LDP base protocol.  Following the policies outlined in [IANA], TLV types in this range are allocated through an IETF Consensus action.
-  TLV Types 0x3E00 - 0x3EFF.  TLV types in this range are reserved for Vendor-Private extensions and are the responsibility of the individual vendors (see Section "LDP Vendor-Private TLVs").  IANA management of this range of the TLV Type Name Space is unnecessary.
-  TLV Types 0x3F00 - 0x3FFF.  TLV types in this range are reserved for Experimental extensions and are the responsibility of the individual experimenters (see Sections "LDP Experimental Extensions" and "Experiment ID Name Space").  IANA management of this range of the TLV Name Space is unnecessary; however, IANA is responsible for managing part of the Experiment ID Name Space (see below)."

  The TLV Type name space is divided into 3 regions but they appear to be not as stated - IETF Consensus region, First Come First Served region, and Private Use region. Rather the division appears to be as follows:

1. LDP Base protocol - allocated through IETF Consensus action.

2. Vendor-Private extensions - IANA management is unnecessar

3. Experimental - IANA management is unnecessary

Security Directorate review from Richard Barnes.

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This document extends the matching capabilities of the LDP Wildcard 
FEC element, which matches all Forwarding Equivalence Classes bound to 
a given label, by adding a second Typed Wildcard FEC element, which 
matches all FECs of a given type, with optional additional type-
specific constraints.  Because this change is relatively minor, the 
security considerations are mostly the same as the base protocol, as 
noted by the Security Considerations section; however, I would prefer 
if the authors explained a little better why this is the case.

From an editorial perspective, this document is unclear on several 
important points, especially with regard to the type-specific 
constraints and how they are defined and managed.  I think the 
document would would benefit from another revision, focused on making 
the meaning and management of all parameters clear to ensure 
interoperability.

Detailed comments follow.

--Richard



Specific comments:

Section 1, Para "As specified..."
With respect to the phrase "relative to an optional constraint": I 
don't see anything in RFC 5036 that allows for such a constraint.  The 
Wildcard FEC type "is to be applied to all FECs associated with the 
label within the following label TLV."

Section 1, Para "1. The Wildcard FEC Element is untyped"
It's not quite accurate to say that the element is untyped; it has 
type 0x01.  Suggest something like "The Wildcard FEC element only 
allows very coarse selection of FECs by label."

Section 1, General
Clearly you're really after here isn't to change the Wildcard FEC 
Element (as the last sentence of the section says), but to have a new 
element that is a typed Wildcard.  It would be clearer and more 
accurate to say this, e.g., in bullet (2), "There are situations where 
it would be useful to have a wildcard-like FEC Element, with type 
constraints, in Label Request messages."

Section 2, TLV
s/Lenth/Length/

Section 3, Para "The Typed Wildcard FEC Element..."
The language about constraints here seems vague.  (In what sense is 
the constraint "optional"?)  Suggest the following:
"
A Typed Wildcard FEC Element specifies a FEC Type and, optionally, a 
constraint.  An element of this type refers to all FECs of the 
specified FEC Type that meet the constraint.  The format of the 
constraint field depends on the FEC Type specified.
"

Section 3, Para "Additional FEC Type-specific Information ..." et seq
It is unclear whose responsibility it is to define the structure of 
this field (i.e., who is the "designer"?).  Do you mean to say this: 
"Additional constraints that the FEC must satisfy in order to be 
selected. The format of the Additional FEC Type-specific Information 
depends on the FEC type in question.  This document defines the format 
of this field for the Prefix FEC type."
The text here and in the document suggest that there should perhaps be 
a procedure for defining and registering formats for this field. 
However, you may want to specify that any FEC Type may be specified 
with a zero-length Additional FEC Type-specific Information field to 
simply match all FECs of that FEC Type (in order to make it easy to 
use without a whole lot of new RFCs).

Section 4, Para "It is the responsibility..." et seq
The authors of this document are the designers of the Typed Wildcard 
FEC Element Type; who do you mean?  It is meaningless to have a MUST 
that is conditional on "making sense".

Section 4, Para "When a FEC TLV..."
This constraint made sense for the generic Wildcard type, since that 
would overwhelm any other FEC Elements, but it's not clear why it's 
necessary here.  Couldn't I have a Label Withdraw message that 
withdraws all CR-LSP FECs and a single Prefix FEC?

Section 6, General
You need to specify the semantics of this field.  Does it match all 
FECs that are of the given address family?  Also, this doesn't allow 
any constraints on prefix length or the prefix itself; is that 
intentional?

Section 7, Para "In other words ..."
s/can not/MUST NOT/

Section 9, General
I would like to see a little more explanation of why this extension to 
LDP does not create additional security considerations.  It seems like 
at the very least it increases the risk of misconfiguration by adding 
much more flexible wildcard matching rules; that is, it seems more 
likely that an LSR operator will accidentally match things he doesn't 
intend to, or vice versa.

IANA comments:

Action 1:

Upon approval of this document, IANA will make the following
assignment in the "FEC TYPE NAME SPACE" registry at
http://www.iana.org/assignments/ldp-namespaces

Value Hex Name Reference
------- ----- ----------------------------- ---------
TBD(5) TBD Typed Wildcard FEC Element [RFC-mpls-ldp-typed-wildcard-05]


Action 2:

Upon approval of this document, IANA will make the following
assignment in the "TLV TYPE NAME SPACE" registry at
http://www.iana.org/assignments/ldp-namespaces

Range Description Reference
----------------- ----------------------------------- ---------
TBD Typed Wildcard FEC Capability
[RFC-mpls-ldp-typed-wildcard-05]

We understand the above to be the only IANA Actions for this document.

Intended status : Standards Track

> (1.a) Who is the Document Shepherd for this document? Has the
> Document Shepherd personally reviewed this version of the
> document and, in particular, does he or she believe this
> version is ready for forwarding to the IESG for publication?

Loa Andersson is the document shepherd.

He has personally reviewed the I-D and believes it is ready for
forwarding to the IESG for publication.

> (1.b) Has the document had adequate review both from key WG members
> and from key non-WG members? Does the Document Shepherd have
> any concerns about the depth or breadth of the reviews that
> have been performed?

This document has been reviewed by the MPLS working group.


> (1.c) Does the Document Shepherd have concerns that the document
> needs more review from a particular or broader perspective,
> e.g., security, operational complexity, someone familiar with
> AAA, internationalization or XML?

No concerns.

> (1.d) Does the Document Shepherd have any specific concerns or
> issues with this document that the Responsible Area Director
> and/or the IESG should be aware of? For example, perhaps he
> or she is uncomfortable with certain parts of the document, or
> has concerns whether there really is a need for it. In any
> event, if the WG has discussed those issues and has indicated
> that it still wishes to advance the document, detail those
> concerns here. Has an IPR disclosure related to this document
> been filed? If so, please include a reference to the
> disclosure and summarize the WG discussion and conclusion on
> this issue.


No concerns. The document is sound.
No IPR disclosures filed.

> (1.e) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with
> others being silent, or does the WG as a whole understand and
> agree with it?

There were no problems with consensus for this document. The document
has been carefully reviewed and all comments addressed.

> (1.f) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in
> separate email messages to the Responsible Area Director. (It
> should be in a separate email because this questionnaire is
> entered into the ID Tracker.)

No threats. No discontent.

> (1.g) Has the Document Shepherd personally verified that the
> document satisfies all ID nits? (See
> http://www.ietf.org/ID-Checklist.html and
> http://tools.ietf.org/tools/idnits/). Boilerplate checks are
> not enough; this check needs to be thorough. Has the document
> met all formal review criteria it needs to, such as the MIB
> Doctor, media type and URI type reviews?

All checks made. Thanks to timing, the draft incorporates the new boilerplate post 2/12/2009.



> (1.h) Has the document split its references into normative and
> informative? Are there normative references to documents that
> are not ready for advancement or are otherwise in an unclear
> state? If such normative references exist, what is the
> strategy for their completion? Are there normative references
> that are downward references, as described in [RFC3967]? If
> so, list these downward references to support the Area
> Director in the Last Call procedure for them [RFC3967].

References split.

Note: The ID nits tool thinks there is an outdated informative reference
to RFC3036, but the reference is correct since it discusses difference
between RFC3036 and RFC5036.


> (1.i) Has the Document Shepherd verified that the document IANA
> consideration section exists and is consistent with the body
> of the document? If the document specifies protocol
> extensions, are reservations requested in appropriate IANA
> registries? Are the IANA registries clearly identified? If
> the document creates a new registry, does it define the
> proposed initial contents of the registry and an allocation
> procedure for future registrations? Does it suggest a
> reasonable name for the new registry? See [RFC2434]. If the
> document describes an Expert Review process has Shepherd
> conferred with the Responsible Area Director so that the IESG
> can appoint the needed Expert during the IESG Evaluation?

A IANA section is present requesting codepoints for:

- a new LDP FEC Element Type
- a new LDP Capability



> (1.k) The IESG approval announcement includes a Document
> Announcement Write-Up. Please provide such a Document
> Announcement Write-Up. Recent examples can be found in the
> "Action" announcements for approved documents. The approval
> announcement contains the following sections:
>
> Technical Summary
> Relevant content can frequently be found in the abstract
> and/or introduction of the document. If not, this may be
> an indication that there are deficiencies in the abstract
> or introduction.


The LDP specification [RFC5036] for the Wildcard FEC element has
several deficiencies. This document corrects those deficiencies. In
addition, it specifies the Typed Wildcard FEC for the Prefix FEC
Element Type defined in RFC5036.


The RFC5036 specification of the Wildcard FEC Element has the
following deficiencies which limit its utility:

1) The Wildcard FEC Element is untyped. There are situations where
it would be useful to be able to refer to all FECs of a given
type.

2) Use of the Wildcard FEC Element is limited to Label Withdraw and
Label Release messages only. There are situations where it would
be useful in Label Request messages.

This document:

- Addresses the above deficiencies by defining a Typed Wildcard
FEC Element and procedures for its use.

- Specifies use of the LDP capability mechanism [RFC5561] at
session establishment time for informing a peer that an LDP
speaker is capable of handling the Typed Wildcast FEC.

- Specifies the Typed Wildcard FEC Element for the Prefix FEC
Element specified by RFC5036.

Note that this document does not change procedures specified for the
LDP Wildcard FEC Element by RFC5036.




> Working Group Summary

> Was there anything in WG process that is worth noting? For
> example, was there controversy about particular points or
> were there decisions where the consensus was particularly
> rough?

Nothing of note.

> Document Quality

> Are there existing implementations of the protocol? Have a
> significant number of vendors indicated their plan to
> implement the specification? Are there any reviewers that
> merit special mention as having done a thorough review,
> e.g., one that resulted in important changes or a
> conclusion that the document had no substantive issues? If
> there was a MIB Doctor, Media Type or other expert review,
> what was its course (briefly)? In the case of a Media Type
> review, on what date was the request posted?

There is at least one implementation that we know of, i.e. Cisco.