Re: [mpls] MPLS-RT review of draft-smack-mpls-rfc4379bis

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Fri, 11 December 2015 14:21 UTC

Return-Path: <cpignata@cisco.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7995D1AD06B; Fri, 11 Dec 2015 06:21:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level:
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUBai4qgLtck; Fri, 11 Dec 2015 06:21:06 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DEA81ACF5B; Fri, 11 Dec 2015 06:21:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11530; q=dns/txt; s=iport; t=1449843661; x=1451053261; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pmP0OVxVbmJsw9SKfJypckxbaYvB7x9URKDC18w/8yE=; b=D4HeAIpm/XDBWcpY9JNROzDePCMGEk0yWXBG/aewnm8Ft96tMTz0T/v+ fNlb/bV6ZqofCwsFgZAxsfA01qIY2oz7Fm2MQANDB+QS/TUfIDzaIFVJ7 6MEYWEybd6cxea2OS9u8TQKvJFtDKu0jXdy4mRJis4tixH1L3zeuABxaU A=;
X-Files: signature.asc : 841
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AVAwAp22pW/5BdJa1egm5MU24GuxCCGQ6BYiGFbgKBLzgUAQEBAQEBAYEKhDQBAQEDASNWBQsCAQgYJwMCAiERFBECBA4FDogMAwoIDaxsjTINhEQBAQEBAQEBAQEBAQEBAQEBAQEBAQEPCYZWgg+CboJTgj6CZi+BGgWTAoNwAYJogWJqhVRDgXiBWxYzkguBB4Nng3IBHwFDhARyAQGEToEHAQEB
X-IronPort-AV: E=Sophos;i="5.20,413,1444694400"; d="asc'?scan'208,217";a="217011909"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Dec 2015 14:21:00 +0000
Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id tBBEL0tq022226 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 11 Dec 2015 14:21:00 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 11 Dec 2015 09:20:59 -0500
Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Fri, 11 Dec 2015 09:20:48 -0500
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Kireeti Kompella <kireeti.kompella@gmail.com>
Thread-Topic: MPLS-RT review of draft-smack-mpls-rfc4379bis
Thread-Index: AQHRM57SJVRft+1rxkCzgT3Swczfzp7GKtWA
Date: Fri, 11 Dec 2015 14:20:48 +0000
Message-ID: <0A56B6D3-6766-4F8E-BB91-9A1963026A10@cisco.com>
References: <564E8331.5070708@pi.nu> <BY2PR0501MB181301588EFC3001B95D1339BD0C0@BY2PR0501MB1813.namprd05.prod.outlook.com> <CABRz93XjPCGUHzGMxj5zj_cKJuQM2wahX_Ah=QGYc9xzNVPDeg@mail.gmail.com>
In-Reply-To: <CABRz93XjPCGUHzGMxj5zj_cKJuQM2wahX_Ah=QGYc9xzNVPDeg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.150.54.97]
Content-Type: multipart/signed; boundary="Apple-Mail=_F4CA672A-9546-485F-8A05-3F70A0932C4D"; protocol="application/pgp-signature"; micalg="pgp-sha256"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/J8aFDogmUfRJ73widsCyVR2pBk4>
Cc: "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "draft-smack-mpls-rfc4379bis@ietf.org" <draft-smack-mpls-rfc4379bis@ietf.org>
Subject: Re: [mpls] MPLS-RT review of draft-smack-mpls-rfc4379bis
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Fri, 11 Dec 2015 14:21:08 -0000

> On Dec 10, 2015, at 6:01 PM, Kireeti Kompella <kireeti.kompella@gmail.com> wrote:
> 
> Hi Yimin,
> 
> Thanks for your review!
> 
> On Fri, Dec 4, 2015 at 10:17 PM, Yimin Shen <yshen@juniper.net <mailto:yshen@juniper.net>> wrote:
> Hi authors,
> 
> I was selected as a reviewer for the draft-smack-mpls-rfc4379bis, and I have completed my review.
> 
> I think this draft is useful, providing an overdue update for RFC 4379, which is the base RFC of a widely deployed protocol in MPLS networks.
> 
> One issue I have is that the draft is still specifying the packet format and mechanisms based on the Downstream Mapping TLV, which has been deprecated by the Downstream Detailed Mapping TLV defined by RFC 6424. I notice the section 1.5 where it briefly mentions the evaluation of incorporating some new RFCs to this draft. But it is unclear to me what the decision will be, whether the draft would stop here to provide just backward compatibility or it will take further steps to incorporate RFC 6424. So, before the draft is adopted, I'd like to see draft progress a little further on the to-do list and give and clearer strategy on this.
> 
> I don't really care whether this is done before or after WG adoption.  However, one question for the WG is, should deprecated TLVs be moved into an appendix?  Sort of as follows:
> 
> 3.2.8 <http://tools.ietf.org/html/rfc4379#section-3.2.8>.  FEC 128 Pseudowire (Deprecated)
> 
> (See Appendix A for details.)
> 
> 3.2.9 <http://tools.ietf.org/html/rfc4379#section-3.2.9>.  FEC 128 Pseudowire (Current)
> 
> ...
> 
> [and of course put the text currently in section 3.2.8 in the Appendix.]  This preserves the historical stuff while moving them out of the way of implementors.
> 
> Cheers,
> Kireeti.
> 

I think that moving deprecated items to an Appendix is useful and will help clean up the spec.

Thanks!

— Carlos.

> Thanks,
> 
> /Yimin Shen
> 
> 
> 
> 
> --
> Kireeti