Re: [Idr] Working Group Last Call for draft-chen-bgp-ext-opt-param-02

[Enke Chen <[e-mail]>]

Hi, John:

The dynamic capability is a big hammer for this small nail :-)

While the dynamic capability is generic, I suspect that only a very 
small subset of capabilities (such as address families) will be 
implemented and made dynamic - due to complexities involved and the 
absence of the requirements for most of the capabilities.  Thus I 
believe that the solution offered in draft-checn-bgp-ext-opt-param-02 is 
necessary, and it is a better solution due to its simplicity (though 
"hacky" as pointed out).

Regards,   -- Enke


John Leslie wrote:
> Rob Shakir <[e-mail]> wrote:
>   
>> On 12 Feb 2010, at 17:09, John Leslie wrote:
>>
>>     
>>>   And, it's a poor fit to the item in our proposed Revised Charter:
>>> " 
>>> " - Specify a means to non-disruptively introduce new BGP Capabilities
>>> " to an existing BGP session.
>>>
>>> I support that as a work item; and it implies that there must be
>>> a way to advertise capabilities while a session remains OPEN. Thus
>>> (if the Revised Charter is adopted) we must define an (optional) new
>>> message format to carry Capability Advertisements, removing any need
>>> to crowd all capabilities into one OPEN message.
>>>       
>> I am not entirely sure that this is true.
>>     
>
>    "Any need" may seem to overstate the case: I was thinking that there
> could be no need if your peer _supports_ dynamic capabilities.
>
>    I agree there _could_ be a need to crowd capabilities into one OPEN
> message when you know you're speaking to a peer with no support (at all)
> of receiving Capability advertisements after the OPEN (which of course
> you can't know if you're the first to send an OPEN).
>
>    I am not aware of any cases which come anywhere close to the 704
> byte "theoretical maximum" on John Scudder's slides; and I'm pretty
> sure that dynamic capabilities would be a better solution than revising
> the OPEN message. If I'm wrong on either of these, please say so.
>
>   
>> Are there situations in which one would want a session to be opened
>> with a specific set of capabilities, and not even entertain the idea
>> that there might be further capabilities added to these?
>>     
>
>    This is possible, but seems less than reasonable if your BGP speaker
> supports dynamic capabilities.
>
>   
>> (I'm not sure that this is actually a concern in any deployment that
>> I am currently aware of, one would expect that if the capability is
>> not supported at one end, a request to add it is not a disaster.)
>>     
>
>    I agree: at worst, it would require a NAK; and in most cases it's
> entirely safe to ignore a capability advertisement.
>
>   
>> The other point that I can think of is that there is some "duplicate
>> work being done by a BGP speaker if it is unable to send an OPEN with
>> the full set of its capabilities, and instead needs to send an OPEN
>> and then negotiate any capabilities.
>>     
>
>    Unfortunately there's "duplicate work" in any case...
>
>    IMHO, the case you name is at least clean: you learn that your peer
> won't listen to dynamic capabilities, so you close and open with the
> capabilities you care most to advertise. (For that matter, if you know
> that list ahead of time, you can include all of them in the first OPEN.)
>
>    Under draft-chen-bgp-ext-opt-param, you must first send all the
> capabilites you care about; then see whether your peer sends you a
> NOTIFICATION saying in essence "I don't understand ext-opt-param;"
> then send an OPEN scaled back to a set that fits in 256 bytes.
>
>    This is messy: it's easy to imagine implementations that send
> slightly different NOTIFICATIONS...
>
>   
>> I agree with John here, at worst this would appear to be an overlap
>> - and there would appear to be no harm in progressing this proposal.
>>     
>
>    "No" harm is overstating the case: publishing ext-opt-param as
> an RFC takes significant effort; coding it in "all" implementations
> takes significant time and effort; and the complexity it introduces
> increases the chances of late bugs.
>
>   
>> The draft would mitigate the situation that there is some period
>> in which we need >255 bytes in the Optional Parameters, and there [is]
>> no (stable ;-)) implemented dynamic capabilities support.
>>     
>
>    A situation I would be most happy to avoid!
>
>    The sooner we finish off draft-ietf-idr-dynamic-cap, the less chance
> such a period will occur. The simpler we make it, the less chance
> stable implementation won't be available.
>
>    I would suggest we strip draft-ietf-idr-dynamic-cap of anything which
> really is a matter of "tuning", and clarify that a NAK is perfectly
> acceptable to a request to withdraw an advertised capability. This would
> enable partial implementations to ship and get field-testing.
>
>    (Heck, NAK should be acceptable to _anything_ you don't want to
> bother with: it's just that "ordinary" capabilities can safely be
> completely ignored.)
>
>    Limiting an implementation to the same functions now done during
> processing of capability advertisements currently parsed during an OPEN
> would greatly reduce the likelihood of non-stable implementations.
>
>    We _really_should_ resist the temptation to crowd too much into any
> particular BGP extension...
>
> --
> John Leslie <[e-mail]>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>