Re: [mpls] Last Call: draft-ietf-mpls-ldp-upstream (MPLS Upstream Label Assignment for LDP) to Proposed Standard

lizhong.jin@zte.com.cn Thu, 14 October 2010 04:03 UTC

Return-Path: <lizhong.jin@zte.com.cn>
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 C33BD3A68A3; Wed, 13 Oct 2010 21:03:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.25
X-Spam-Level:
X-Spam-Status: No, score=-103.25 tagged_above=-999 required=5 tests=[AWL=-1.412, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
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 kFKkOqqg0C-z; Wed, 13 Oct 2010 21:03:19 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 002733A688A; Wed, 13 Oct 2010 21:03:18 -0700 (PDT)
Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 205952203882679; Thu, 14 Oct 2010 12:01:39 +0800 (CST)
Received: from [10.32.0.74] by [192.168.168.16] with StormMail ESMTP id 38058.4076583345; Thu, 14 Oct 2010 12:01:52 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse3.zte.com.cn with ESMTP id o9E42m6l087859; Thu, 14 Oct 2010 12:02:49 +0800 (CST) (envelope-from lizhong.jin@zte.com.cn)
In-Reply-To: <mailman.64.1285959611.9349.mpls@ietf.org>
To: erosen@cisco.com
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OFCD99C4ED.4E94C831-ON482577BC.0014DB16-482577BC.0016376B@zte.com.cn>
From: lizhong.jin@zte.com.cn
Date: Thu, 14 Oct 2010 12:01:53 +0800
X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2010-10-14 12:02:40, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2010-10-14 12:02:40, Serialize complete at 2010-10-14 12:02:40, S/MIME Sign failed at 2010-10-14 12:02:40: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-14 12:02:40
Content-Type: multipart/alternative; boundary="=_alternative 00163768482577BC_="
X-MAIL: mse3.zte.com.cn o9E42m6l087859
Cc: mpls@ietf.org, pwe3@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
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, 14 Oct 2010 04:03:22 -0000

Hi all,
I am looking forward the consensus from WG and IESG. The same issue 
(RFC3212) happens to draft-ietf-pwe3-dynamic-ms-pw-13 (although not last 
call currently). What's more, such kind of consensus can also give some 
guidance to other SDO.

BR
Lizhong
 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Thu, 30 Sep 2010 15:31:01 -0400
> From: Eric Rosen <erosen@cisco.com>
> Subject: Re: [mpls] Last Call: draft-ietf-mpls-ldp-upstream (MPLS
>    Upstream   Label Assignment for LDP) to Proposed Standard
> To: ietf@ietf.org
> Cc: mpls@ietf.org
> Message-ID: <26461.1285875061@erosen-linux>
> 
> 
> 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".
> 
> 
> 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.