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

["Jakob Heitz (jheitz)" <[e-mail]>]

I can agree to using a new BGP OPEN Optional Parameter.

I would add that if after receiving the OPEN message, the BGP neighbor closes the session
with “Unsupported Optional Parameters”, that the sender of that OPEN message try
opening the session again without the version parameter.

Graceful restart is affected. When a restarted session is restarted a second time,
stale markings are removed. To prevent that, when a neighbor has previously restarted a session
due to not supporting the new version parameter, a session that is restarted due to GR should not
include the version parameter.

Regards,
Jakob.

From: Idr <[e-mail]> On Behalf Of Robert Raszuk
Sent: Saturday, January 14, 2023 4:50 AM
To: Gyan Mishra <[e-mail]>
Cc: Bruno Decraene <[e-mail]>; Donatas Abraitis <[e-mail]>; IDR List <[e-mail]>
Subject: Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25


> can be helpful in troubleshooting capability exchange issues.

Nope .. sorry.

In any BGP speaker actual BGP capabilities are sent based on configuration not based on the version of the BGP implementation. So to help in troubleshooting capability exchange issues you would need to get all the bgp config of the peer. Is this next what is coming as free form text here ?

And pls do observe that I am not against the idea. In fact as I said I like it. But not as encoded in BGP Capabilities Type 2 of BGP OPEN Optional Parameters

Best regards,
R.


On Sat, Jan 14, 2023 at 7:09 AM Gyan Mishra <[e-mail]<mailto:[e-mail]>> wrote:
Hi Robert

In the open message this is just an optional parameter “meta data” URI  encoding that is stuffed in the field and so does not need to be negotiated, so harmless,  but can be helpful in troubleshooting capability exchange issues.  Even if the router had a bug and sent the wrong meta data it would be harmless.

Kind Regards

Gyan

On Fri, Jan 13, 2023 at 4:10 AM Robert Raszuk <[e-mail]<mailto:[e-mail]>> wrote:
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]<mailto:[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]<mailto:[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.
>
_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347