Re: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-extended-experimental-00.txt]

"Dongjie (Jimmy)" <jie.dong@huawei.com> Wed, 02 November 2016 03:20 UTC

Return-Path: <jie.dong@huawei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4102129851 for <idr@ietfa.amsl.com>; Tue, 1 Nov 2016 20:20:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.718
X-Spam-Level:
X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 AFXusjmJEooR for <idr@ietfa.amsl.com>; Tue, 1 Nov 2016 20:20:49 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B89201294F9 for <idr@ietf.org>; Tue, 1 Nov 2016 20:20:48 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZN03439; Wed, 02 Nov 2016 03:20:46 +0000 (GMT)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 2 Nov 2016 03:20:45 +0000
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Wed, 2 Nov 2016 11:20:37 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Jeffrey Haas <jhaas@pfrc.org>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-extended-experimental-00.txt]
Thread-Index: AQHSM7jIewH/rzAmpkOieaXMd4f3MqDE923g
Date: Wed, 2 Nov 2016 03:20:37 +0000
Message-ID: <76CD132C3ADEF848BD84D028D243C927935045D8@NKGEML515-MBX.china.huawei.com>
References: <20161031205515.GA25507@pfrc.org>
In-Reply-To: <20161031205515.GA25507@pfrc.org>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.130.151.75]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.58195B8F.0001, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 76d5b2ea2ba801e083fdc5670f46e6ce
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/b0hzMGPWUd4mIeXzz7H8DfS2SjE>
Subject: Re: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-extended-experimental-00.txt]
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Nov 2016 03:20:51 -0000

Hi Jeff, 

Thanks for uploading this draft, recently I also had some relevant discussion with people offline. Other protocols such as LDP already provide the mechanism for vendor specific extension, and several features have been developed based on that. Maybe it is the time to discuss whether similar mechanism is also needed in BGP, so I think this draft is quite useful. 

Some quick comments about the current draft:

1. In introduction, it describes the consequence of conflicting attribute parsing error according to RFC 4271, while the consequence according to RFC 7606 is less disruptive, it may also be described here, which is either discarding the attribute or treating the update as withdraw. 

2. In the TLV of Extended Experimental Attribute, several fields are further defined after the "Implementor IANA Private Enterprise Number" field, while many implementers may follow this design under their Private enterprise number, the mechanism chosen in LDP may also be considered, in which the format of data after the Length and vendor-ID field are vendor-dependent. 

3. As the Extended Experimental Attribute can contain a series of TLVs, is it possible that TLVs belonging to different vendors, or TLVs of different features are carried in this attribute? If this is the case, further specification about the processing of unrecognized TLVs and the error handling would be needed. 

Best regards,
Jie

> -----Original Message-----
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas
> Sent: Tuesday, November 01, 2016 4:55 AM
> To: idr@ietf.org
> Subject: [Idr] [internet-drafts@ietf.org: I-D Action:
> draft-haas-idr-extended-experimental-00.txt]
> 
> IDR,
> 
> There's a larger conversation to be had about proper stewardship and use of
> code points of all sorts, but path attributes have our attention for the moment.
> 
> A quick draft for consideration and to motivate discussion.
> 
> -- Jeff
> 
> P.S. I'm sure there's a number of rough edges in this.  I knocked it off in less than
> two hours after not enough sleep.
> 
> ----- Forwarded message from internet-drafts@ietf.org -----
> 
> Date: Sun, 30 Oct 2016 07:53:04 -0700
> From: internet-drafts@ietf.org
> To: i-d-announce@ietf.org
> Subject: I-D Action: draft-haas-idr-extended-experimental-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>         Title           : Extended Experimental Path Attributes for BGP
>         Author          : Jeffrey Haas
> 	Filename        : draft-haas-idr-extended-experimental-00.txt
> 	Pages           : 7
> 	Date            : 2016-10-30
> 
> Abstract:
>    BGP's primary feature extension mechanism, Optional-Transitive Path
>    Attributes, has proven to be a successful mechanism to permit BGP to
>    be extended.  In order to ease various issues during the development
>    of new BGP features, this document proposes an extended experimental
>    path attribute to carry prototype features.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-haas-idr-extended-experimental/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-haas-idr-extended-experimental-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> ----- End forwarded message -----
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr