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

[Robert Raszuk <[e-mail]>]

Enke and all,

I support progressing the draft to the RFC.

I don't think that what is in fact proposed in the draft is that 
"hacky". Assigning a special meaning to a given value (here 255) is IMHO 
a natural way to extend the available space.

Of course there could be other ways to extend the capability space .. 
mark other value to mean OPEN2 msg will follow .. introduce hierarchy 
within each AF etc .. but those would be truly hacky or at least much 
more hacky :-).

Cheers,
R.


> 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
>>   
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>