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

[Gyan Mishra <[e-mail]>]

Got it, Thanks for clarification.

On Sat, Jan 14, 2023 at 7:50 AM Robert Raszuk <[e-mail]> wrote:

>
> > 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]> 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]> 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*
>>
>> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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



*M 301 502-1347*