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

[Gyan Mishra <[e-mail]>]

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]> 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]> 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.
>> >
>>
>> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*