Re: [mpls] Last Call comments on ldp upstream label allocation

[Rahul Aggarwal <rahul at juniper.net>]

Hi Eric,

Thanks for the comments. Please see below:

On Fri, 30 Oct 2009, Eric Rosen wrote:

>
> I have a couple of comments on draft-ietf-mpls-ldp-upstream-04.
>
> The draft has a normative reference to RFC 3472 "Generalized Multi-Protocol
> Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution
> Protocol (CR-LDP) Extensions".  I don't think this is allowable, as we do
> not want to take any action that prevents the deprecated CR-LDP documents
> from being reclassified as historic.
>
> Section 4.3 of RFC 3468 "The Multiprotocol Label Switching (MPLS) Working Group
> decision on MPLS signaling protocols" says:
>
>    Consequently we need to keep CR-LDP referenceable, i.e., on the
>    standards track, for the foreseeable future.  The implication of this
>    is not that we need to progress it further, or need to undertake
>    further work in the area.  One implication however is that standards
>    organizations which reference the document, need to be notified of
>    our decision so that they (at their own pace) can change their
>    references to more appropriate documents.
>
> I would interpret this as implying that the IETF should not be creating
> normative references to CR-LDP documents.  (If we expect other organizations
> to be changing their references to the CR-LDP documents, we shouldn't be
> creating new references to them.)  Note that RFC 3468 explicitly calls out
> RFC 3472 as one of the deprecated documents.
>
> The normative reference is due to the draft's reuse of the "Interface ID
> TLV" defined in RFC 3472.  If this TLV is to be used, it would be better to
> define it in the ldp-upstream draft and to have IANA change the reference in
> the iana.org registry.
>

It is not clear that we have a problem with the draft's
reference of the "Interface ID TLV" (as defined in rfc3472).
This is because rfc3468 makes it very clear that CR-LDP is
"referenceable, i.e., on the standards track, for the
foreseeable future", and thus there should be no problem for us
to reference rfc3472.

> However, it is questionable whether the Interface ID TLV is really the right
> TLV for ldp-upstream to use, as the interface ID TLV has fields that are do
> not appear to be needed in ldp-upstream (e.g., "next/previous hop", "logical
> inteface id").
>

The issue with the next/previous hop and logical interface id
is easy to fix. If there are no objections from the WG, then I
will specify in the LDP upstream draft that the next/previous
hop and logical interface id should be set to 0 by the sender
and ignored by the receiver.

> One more comment: the "LDP Tunnel Identifiers" defined in section 5 of
> ldp-upstream do not appear to be exactly the same in all cases as the "PMSI
> Tunnel Attribute Tunnel Identifiers" defined in section 5 of draft-ietf-
> l3vpn-2547bis-mcast-bgp-08.txt.  (E.g., the means of identification of
> RSVP-TE tunnels seems to be different.)

I will replace "1. RSVP-TE P2MP LSP TLV. Type = TBD. Value of he TLV
is the RSVP-TE P2MP Session Object and optionally the P2MP Sender
Template Object [RFC4875]."

with:

"1. RSVP-TE P2MP LSP TLV. Type = TBD. Value of the TLV is
 <Extended Tunnel ID, Reserved, Tunnel ID, P2MP ID> as carried in the
RSVP-TE P2MP LSP SESSION Object [RFC4875]."

rahul