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

["Dongjie (Jimmy)" <[e-mail]>]

Hi Jeff, 

> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Wednesday, November 02, 2016 9:54 PM
> To: Dongjie (Jimmy) <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Idr] [[e-mail]: I-D Action:
> draft-haas-idr-extended-experimental-00.txt]
> 
> 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.

Understood. As you said, a little more text would be enough.

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

Yes, the type 0x3E00 - 0x3EFF is a reserved range of LDP TLVs for vendor specific extensions, and the type and Vendor ID field together specify how the Data field should be interpreted. At first I thought the type of LDP TLV is analogous to the type of BGP path attribute, while in implementations it is used to identify a particular vendor-private feature. 

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

This is fine to me as long as it can identify different vendors.

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

Agree version information can help the troubleshooting of interoperability issues.

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

To my understanding, the optional transitive attribute in BGP is analogous to an LDP TLV with both U and L bit set, so IMO no further bits are required for BGP. 

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

Understood and totally agree to make this part simple at current stage. While for some experiments in which devices from multiple vendors are involved, it may be possible that different TLVs are carried in this attribute. With LDP this is simpler, as different features are carried in different LDP TLVs and can be processed independently. Of course this can be left for further discussion.

Best regards,
Jie

> 
> -- Jeff