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

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