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

[Robert Raszuk <[e-mail]>]

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.

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

The only difference seems to be MUST in RFC4271 in respect to Unsupported
Optional Parameters vs MAY in RFC5492 in respect to Unsupported Capability.

Thx,
r.


On Thu, Jan 12, 2023 at 6:40 PM John Scudder <[e-mail]> wrote:

> > On Jan 11, 2023, at 11:07 AM, Robert Raszuk <[e-mail]> wrote:
> >
> > >  I think what you're intending to type is encoding the version
> capability in a new optional parameter
> > > different than a capability optional parameter.
> >
> > Yes and I am not insisting on the choice of any specific encoding.
>
> For those who don’t remember the history you may want to take a look at
> RFC 4271 Section 6.2:
>
>    If one of the Optional Parameters in the OPEN message is not
>    recognized, then the Error Subcode MUST be set to Unsupported
>    Optional Parameters.
>
> That is, any RFC 4271 compliant implementation that receives an OPEN
> Optional Parameter that it doesn’t recognize will reset the session. This
> is exactly the reason Capabilities were introduced — because we realized
> that the way Optional Parameters were defined doesn’t lend itself to the
> introduction of new parameters.
>
> AFAICT it would be a nonstarter to use a new Optional Parameter for the
> application under discussion.
>
> —John