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

[Robert Raszuk <[e-mail]>]

Hello John, Jeff and the WG,

I would like to perhaps make a final point to this discussion in regards to
the last few emails about protocol behavior. I do keep the subject
unchanged as this is directly related to the proposed draft.

It has been pointed out that for almost 22 years (!!) or 13 years BGP
capabilities are supposed to operate in a fashion of peer A sending to peer
B supported capabilities and then peer B using that information to properly
build session to peer A using new SAFI, new BGP Attribute or any other new
encoding.

Controversial aspect of whether peer B should signal peer A "Unsupported
Capability" when it receives one it does not recognize apparently could be
subject to a different thread. Needless to say some implementations do it
today and I would not call them buggy.

But what is important here in this very topic is that proposed extension
in draft-abraitis-bgp-version-capability is not a capability about
something peer A supports or not. *It is the signalling itself. *

So IMO signalling *anything* with zero assurance that peer understands is
not only pointless but could potentially lead to very wrong assumptions (if
at any time sender counts on the other party that such message is received
and understood).

Just imagine BGP running between a plane and ATC before take off. If ATC
sends any messages to the plane and plane simply drops it on the floor as
it does not recognize it - without telling about it to ATC - sooner or
later the disaster may happen.

Hope this makes my POV clear.

Kind regards,
Robert


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

> I see. Since the specified behavior of Capabilities has been as I
> described since RFC 2842 was published almost 22 years ago (!!) I think
> it’s unlikely we’d want to make any major changes to it now — even leaving
> aside any other considerations. I will point out that if anyone actually
> wanted the “reset the session if you don’t support this capability”
> functionality, they have always had it available, in the form of OPEN
> Optional Parameters. Those have been around even longer, since RFC 1771.
>
> I think we’ve probably come to the end of this subtopic but if there’s a
> desire to continue it further I’d suggest moving to a new subject line
> since it’s only tangentially related to draft-abraitis.
>
> —John
>
> > On Jan 12, 2023, at 2:11 PM, Robert Raszuk <[e-mail]> wrote:
> >
> > 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.
> >
>
>