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

From: Rahul Aggarwal <[email-masked]>
Date: Wed, 4 Nov 2009 09:12:46 -0800

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

---

From: Eric Rosen <[email-masked]>
Date: Fri, 06 Nov 2009 13:26:04 -0500

RFC3468> Consequently we need to keep CR-LDP referenceable, i.e., on the
RFC3468> standards track, for the foreseeable future.  The implication of this
RFC3468> is not that we need to progress it further, or need to undertake
RFC3468> further work in the area.  One implication however is that standards
RFC3468> organizations which reference the document, need to be notified of
RFC3468> our decision so that they (at their own pace) can change their
RFC3468> references to more appropriate documents.

Eric> I would interpret this as implying that the IETF should not be
Eric> creating normative references to CR-LDP documents.  (If we expect
Eric> other organizations to be changing their references to the CR-LDP
Eric> documents, we shouldn't be creating new references to them.)  Note
Eric> that RFC 3468 explicitly calls out RFC 3472 as one of the deprecated
Eric> documents.

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

It seems to me to be quite clear that the intention is for the CR-LDP
documents to continue to be "referenceable" by pre-3468 documents, and that
normative references by post-3468 IETF drafts are not "appropriate".

If you're determined for some reason to keep this normative reference to
CR-LDP, I suppose my next step is to ask the WG chairs for a ruling on
this.  WG chairs, do you have an opinion on this process issue?

Your proposed resolutions to my other comments are fine.