Re: [Idr] draft-ietf-idr-ext-opt-param-06.txt - 2 Week WG LC (7/30 to 8/13/2019)

[John Scudder <[e-mail]>]

Wow. Color me embarrassed, and thank you for pointing this out. I think you are right, and furthermore I think it’s a better solution than what we describe in the draft.

Under the circumstances my suggestion to the WG is that we NOT advance the draft to Proposed Standard. The question would remain what to do with it, keeping in mind there are implementations in the wild. The options I can think of are to abandon it, or to publish it as Historic. So, options on the table for the WG are,

1. Abandon the draft.
2. Publish as Historic, because there are implementations out there.

I think in either of the above cases we would also move code 255 to “deprecated”.

3. Continue forward with the original plan of publishing as Proposed Standard, because ______ (fill in the blank if you support this option).

My preference is option 2, although I confess I might be biased by the sunk cost fallacy. :-/

Thanks again for your observation, Ondrej.

—John

> On Aug 8, 2019, at 3:13 PM, Ondrej Zajicek <[e-mail]> wrote:
> 
> On Tue, Jul 30, 2019 at 04:10:49PM +0000, John Scudder wrote:
>> (As a co-author of course.)
>> 
>> Since it seemed helpful last time, here's the elevator pitch for
>> ext-opt-param: We are currently limited to 255 bytes of BGP capabilities.
>> Since many/most BGP extensions want to use a capability, it’s not hard to
>> imagine overrunning the 255 bytes.
> 
> AFAIK we are not currently limited to 255 bytes of BGP capabilities.
> 
> According to RFC 5492, multiple instances of capability options are
> allowed, well-defined, just discouraged:
> 
>   The Capabilities Optional Parameter (OPEN Optional Parameter Type 2)
>   SHOULD only be included in the OPEN message once. ... However,
>   for backward compatibility, a BGP speaker MUST be prepared to receive
>   an OPEN message that contains multiple Capabilities Optional
>   Parameters, each of which contains one or more capabilities TLVs.
> 
> If i want to announce 2k bytes of BGP capabilities, i can just split it
> to multiple sub-256 blocks of capability options. Real limits are 255 bytes
> for each capability and 4k bytes for whole OPEN message.
> 
> While the draft removes per-capability limit by allowing to put all
> capabilities ot one large option, it does that by backward-incompatible way,
> while splitting capabilities to multiple options is backward-compatible.
> 
> -- 
> Elen sila lumenn' omentielvo
> 
> Ondrej 'Santiago' Zajicek (email: [e-mail])
> OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
> "To err is human -- to blame it on a computer is even more so."