Re: [mpls] Last Call: draft-ietf-mpls-ldp-upstream (MPLS Upstream Label Assignment for LDP) to Proposed Standard
Eric Rosen <erosen@cisco.com> Thu, 30 September 2010 19:30 UTC
Return-Path: <erosen@cisco.com>
X-Original-To: mpls@core3.amsl.com
Delivered-To: mpls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E17313A6E6D; Thu, 30 Sep 2010 12:30:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.294
X-Spam-Level:
X-Spam-Status: No, score=-10.294 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+0MHKB6fYfR; Thu, 30 Sep 2010 12:30:21 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 4ED813A6E6E; Thu, 30 Sep 2010 12:30:19 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.57,261,1283731200"; d="scan'208";a="165545509"
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 30 Sep 2010 19:31:01 +0000
Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o8UJV1dc026601; Thu, 30 Sep 2010 19:31:01 GMT
Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id o8UJV1lr026462; Thu, 30 Sep 2010 15:31:01 -0400
To: ietf@ietf.org
In-reply-to: Your message of Wed, 29 Sep 2010 08:21:18 -0700. <20100929152118.21430.23369.idtracker@localhost>
Date: Thu, 30 Sep 2010 15:31:01 -0400
Message-ID: <26461.1285875061@erosen-linux>
From: Eric Rosen <erosen@cisco.com>
Cc: mpls@ietf.org
Subject: Re: [mpls] Last Call: draft-ietf-mpls-ldp-upstream (MPLS Upstream Label Assignment for LDP) to Proposed Standard
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: erosen@cisco.com
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Sep 2010 19:30:32 -0000
With regard to this draft, I need to reiterate a comment I made during WG last call, as I think there is a procedural issue that needs to be brought to the IESG's attention. 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", despite the fact that CR-LDP has been deprecated by RFC 3468 ("The MPLS Working Group decision on MPLS signaling protocols", February 2003). I don't think this is allowable; I interpret RFC 3468 as requiring that we do not take any action that prevents the deprecated CR-LDP documents from being reclassified as historic. The only reason the CR-LDP documents were not classified as historic seven years ago is that there are other standards organizations that have produced specs with normative references to CR-LDP. Section 4.3 of RFC 3468 says: standards organizations which reference the document [the CR-LDP specs], need to be notified of our decision so that they (at their own pace) can change their references to more appropriate documents. It is also expected that they will notify us when they no longer have a need to normative reference to CR-LDP. I think the clear implication of this is that neither the IETF nor any other SDO should be creating new normative references to CR-LDP documents. Note that RFC 3468 explicitly calls out RFC 3472 as one of the deprecated documents. During WG LC, one of the authors stated that he disagreed with my interpretation, but WG consensus on this issue was never obtained. At this point, I believe the only change that is needed to draft-ietf-mpls- ldp-upstream is to move the reference to RFC 3472 into the "Informational References" section. That is, I think that recent revisions to the draft have made the normative reference gratuitous, as one does not need to read RFC3472 in order to implement any part of this draft. If the draft is published with this normative reference, it is almost inevitable that someone will someday say "we don't want to use LDP upstream-assigned labels, because they depend on CR-LDP and CR-LDP has been deprecated".
- [mpls] Last Call: draft-ietf-mpls-ldp-upstream (M… The IESG
- Re: [mpls] Last Call: draft-ietf-mpls-ldp-upstrea… Eric Rosen
- Re: [mpls] Last Call: draft-ietf-mpls-ldp-upstrea… lizhong.jin
- Re: [mpls] Last Call: draft-ietf-mpls-ldp-upstrea… Rahul Aggarwal