Re: [Idr] [[e-mail]: I-D Action: draft-haas-idr-extended-experimental-00.txt]

[Jeffrey Haas <[e-mail]>]

Jie,

On Wed, Nov 02, 2016 at 03:20:37AM +0000, Dongjie (Jimmy) wrote:
> 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. 

Thanks for the comment.  Since I've had a similar comment from others on the
list, a little more text here may be appropriate.  However, I'm trying to
avoid inserting too much of RFC 7606's motivation in here.

> 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. 

Looking at RFC 5036 section 3.6.1.1, I think there's actually good
similarity:
- the LDP vendor-type corresponds to the Implementor Feature Code Point
  Number.  LDP restricts this to one 255 values, which is perhaps a bit
  small.
- The LDP vendor-private Vendor ID uses an IEEE namespace.  I've chosen to
  use an IANA Private Enterprise Number for easy entry into this feature.
  IEEE charges (I believe) for their ID where IANA will give one out to any
  who ask for free.
- The LDP vendor-private field does *not* have a version field.  While it is
  arguable that a given vendor may choose to populate a portion of their
  internal PDU with versioning information, I believe it is strongly
  worthwhile to make this part of the PDU.  We've seen too many issues in
  BGP with regard to versioning issues of features in development to not
  cause the implementor to think about this as a fundamental piece of the
  feature.
- The LDP vendor-private field *does* contain bits related to what to do if
  the field is not understood (U-bit).  Since that behavior causes
  notifications, I'm not sure it's in the spirit of RFC 7606 for BGP.
- The LDP vendor-private F-bit does have somewhat the semantics of a scoping
  bit as has been discussed somewhat earlier in the thread.

> 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. 

There are two intents within the draft:
- If you want to use this attribute, you MUST configure something permitting it.
- Filtering is strongly encouraged.

Currently this draft is tailored toward experiments and development, not
long term deployment of features.  While the conversation is starting to
move toward using this as a generic vendor-specific PA replacement, that's
not the intent of the draft currently.

-- Jeff