Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

[Donatas Abraitis <[e-mail]>]

Thank you, All, for the very great comments/notes. To my understanding:

* It's better to stick with BGP Capability (as the initial version) instead
of BGP OPEN Optional Parameter;
* Requires this new BGP Capability to be used together with rfc9072 (as a
requirement);
* Keep going in IDR, not the ISE track.

Is this correct?

On Thu, Jan 12, 2023 at 9:11 PM Robert Raszuk <[e-mail]> wrote:

> Hi John,
>
> Yes the following example I did not quote was about major support of IPv6.
> But it was just an example.
>
> But my point I think got lost in this discussion. IMO it is a feature not
> a bug to close the session when I am receiving stuff I do not understand.
>
> Please kindly observe that we are not talking about stopping in the middle
> of the flight .. we are talking about taking off or not.
>
> If you follow last paragraph of section 3 of RFC5492 and drop on the floor
> what I am sending to you then it is like I am talking chinese or hindu to
> you and you just ignore it. It does no one any good. In fact disabling this
> on the sender seems like a good thing to do.
>
> With that IMO BGP Capabilities (and perhaps one subset of their dynamic
> flavor) is not the right container to carry unrelated to BGP protocol and
> its operation free form text fields.
>
> So if we were to go for 5492-bis I would instead suggest removing the last
> paragraph of section 3.
>
> Kind regards,
> R.
>
>
>
>
>
>
>
>
>
> On Thu, Jan 12, 2023 at 7:24 PM John Scudder <[e-mail]> wrote:
>
>> > On Jan 12, 2023, at 12:48 PM, Robert Raszuk <[e-mail]> wrote:
>> >
>> >
>> > Hi John,
>> >
>> > But as you see based on real life deployments the very same happens
>> with BGP Capabilities too hence not much of practical difference.
>>
>> I disagree. Yes, it’s true that there have, historically, been
>> implementations that have a bug. Some blame falls to me — that Notification
>> code should never have been called “Unsupported Capability” — even though
>> the spec was ‘right’, the naming was wrong. :-( But I think the updated
>> language in RFC 5492 is explicit enough that anyone still shipping this
>> class of bug almost 13 years after publication has a lot of explaining to
>> do.
>>
>> > And section 3 of RFC5492 allows so ...
>> >
>> >    If a BGP speaker that supports a certain capability determines that
>> >    its peer doesn't support this capability, the speaker MAY send a
>> >    NOTIFICATION message to the peer and terminate peering (see Section
>> >    "Extensions to Error Handling" for more details).
>>
>> No. You’re taking that quote out of context, you left out the example
>> that follows — and that example should already have been enough for you to
>> understand your mistake. The behavior allowed by RFC 5492 is, “if I needed
>> my peer to send me a capability, and it didn’t, then I can close the
>> session”. The problematic behavior with respect to Optional Parameters is
>> “if my peer sent me a parameter I don’t understand, then I must close the
>> session”. These are completely different things. The first is caused by a
>> thing that is not there. The second is caused by a thing that is there. The
>> two examples you sent earlier are a third category, a bug where some
>> implementor decided to do the wrong thing. If it’s a recent version then
>> shame on them, see above.
>>
>> > The only difference seems to be MUST in RFC4271 in respect to
>> Unsupported Optional Parameters vs MAY in RFC5492 in respect to Unsupported
>> Capability.
>>
>> No. See above.
>>
>> The bottom line is, Capabilities are BGP’s main extensibility mechanism.
>> In my opinion (as, to be clear, an individual contributor to the WG) they
>> work OK and are fit for purpose, notwithstanding historical implementation
>> errors. They are suitable for the extension under discussion, just as they
>> are for other extensions.
>>
>> On the other hand, if the WG thinks Capabilities are *not* fit for
>> purpose, the WG should get to work on a replacement that obsoletes and
>> replaces RFC 5492. But saying “oh we’re too scared to extend the protocol
>> because there were bugs in the past” does not seem like a good way to
>> proceed.
>>
>> FWIW, as far as I know, the behavior permitted by the paragraph you quote
>> has never been used. If that’s true, it might not be a bad idea to do an
>> update of RFC 5492 that removes the paragraph and deprecates the
>> Unsupported Capability error code entirely, to avoid future generations
>> going through the same confusion. If the WG wants to do this, I’d be
>> willing to participate, although the first step would be to do a survey to
>> make sure nobody actually is making use of the feature and I’d want someone
>> else to lead on that.
>>
>> —John
>
>

-- 

*Donatas Abraitis*
*Principal Systems Engineer*
@: [e-mail]
W: www.hostinger.com

-- 
This
 message and its attachments may contain privileged and confidential 
information. If you are not the intended recipient, do not use, copy, or
 
disclose this information. Please notify the sender and permanently 
delete 
the message from your system.