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

[Robert Raszuk <[e-mail]>]

> the session resets.

Well let's not forget that this is not like you would "reset" an
established session

Basically with that BGP session would not come up which is different then
to state "session reset". Subsequent open would be tried without this new
optional parameter.

I find it actually a feature to be able to tell compute orchestration that
it's BGP upstream understands this (or other capabilities) or not.
Especially if this is not only to be used by humans but also with some
automation. Spraying blind is questionable and very not deterministic.

Regards,
R.



On Thu, Jan 19, 2023 at 1:00 PM Donatas Abraitis <[e-mail]>
wrote:

> New version:
> https://datatracker.ietf.org/doc/html/draft-abraitis-bgp-version-capability-11
>
> TL;DR; Switched back to BGP Capability. Why? Because if the implementation
> does not support BGP OPEN Optional Parameters, the session resets. Also,
> added RFC9072 as a requirement to avoid exceeding 255 bytes of optional
> parameters length.
>
> On Tue, Jan 17, 2023 at 7:05 AM Gyan Mishra <[e-mail]> wrote:
>
>>
>> At the top of RFC 4271 section 4.5 this is what I am reading that if any
>> open or update message with error sub code is received the session is
>> reset.
>>
>> 4.5 <https://www.rfc-editor.org/rfc/rfc4271#section-4.5>.  NOTIFICATION Message Format
>>
>>    A NOTIFICATION message is sent when an error condition is detected.
>>    The BGP connection is closed immediately after it is sent.
>>
>>
>>
>> That goes for all of the sub codes
>>
>>
>> OPEN Message Error subcodes:
>>
>>                1 - Unsupported Version Number.
>>                2 - Bad Peer AS.
>>                3 - Bad BGP Identifier.
>>                4 - Unsupported Optional Parameter.
>>                5 - [Deprecated - see Appendix A <https://www.rfc-editor.org/rfc/rfc4271#appendix-A>].
>>                6 - Unacceptable Hold Time.
>>
>>       UPDATE Message Error subcodes:
>>
>>                1 - Malformed Attribute List.
>>                2 - Unrecognized Well-known Attribute.
>>                3 - Missing Well-known Attribute.
>>                4 - Attribute Flags Error.
>>                5 - Attribute Length Error.
>>                6 - Invalid ORIGIN Attribute.
>>                7 - [Deprecated - see Appendix A <https://www.rfc-editor.org/rfc/rfc4271#appendix-A>].
>>                8 - Invalid NEXT_HOP Attribute.
>>                9 - Optional Attribute Error.
>>               10 - Invalid Network Field.
>>               11 - Malformed AS_PATH.
>>
>>
>>
>>
>>
>> On Mon, Jan 16, 2023 at 8:21 PM Gyan Mishra <[e-mail]>
>> wrote:
>>
>>>
>>> RFC 4271 section 4.5 states the session is reset for any open or update
>>> notification code.
>>>
>>> RFC 7606 only updates error handling for update messages.  So the
>>> unsupported version number will cause the peer to reset.
>>>
>>> Jakub mentioned this regarding the version capability draft which I
>>> agree is a good option below:
>>>
>>> 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.
>>>
>>> Kind Regards
>>>
>>> Gyan
>>>
>>> On Mon, Jan 16, 2023 at 1:54 PM Linda Dunbar <[e-mail]>
>>> wrote:
>>>
>>>> Gyan,
>>>>
>>>>
>>>>
>>>> RFC4271 states that if the version number is not supported, an error
>>>> message should be sent. But RFC4271 didn’t say if the BGP Open session
>>>> should be failed.
>>>>
>>>> I am just curious if BGP session can be started even if the  version
>>>> number is not supported?
>>>>
>>>>
>>>>
>>>> Linda
>>>>
>>>>
>>>>
>>>> *From:* Gyan Mishra <[e-mail]>
>>>> *Sent:* Saturday, January 14, 2023 12:01 AM
>>>> *To:* Linda Dunbar <[e-mail]>
>>>> *Cc:* Robert Raszuk <[e-mail]>; [e-mail]
>>>> *Subject:* Re: [Idr] WG adoption call for
>>>> draft-abraitis-bgp-version-capability-08, to end September 25
>>>>
>>>>
>>>>
>>>> Hi Linda
>>>>
>>>>
>>>>
>>>> Yes, RFC 7606 provides complete revision of error handling as opposed
>>>> to peer reset which was the error handling with RFC 4271.
>>>>
>>>>
>>>>
>>>> See section 2 and 3.
>>>>
>>>>
>>>>
>>>> All BGP implementations including Open BGP implementations should
>>>> support RFC 7606.
>>>>
>>>>
>>>>
>>>> The main benefit for the versioning is in case the BGP peer
>>>> capabilities exchange is in a one way state and not bidirectional and in
>>>> that case having the version number would help troubleshoot if the
>>>> AFI/SAFi, code-point or parameter is supported or not.
>>>>
>>>>
>>>>
>>>> Kind Regards
>>>>
>>>>
>>>>
>>>> Gyan
>>>>
>>>>
>>>>
>>>> On Fri, Jan 13, 2023 at 4:52 PM Linda Dunbar <
>>>> [e-mail]> wrote:
>>>>
>>>> With so many BGP flavors and versions, is it possible to configure a
>>>> router to ignore the capabilities that it doesn’t support? But still keep
>>>> the BGP session going?
>>>>
>>>>
>>>>
>>>> Linda
>>>>
>>>>
>>>>
>>>> *From:* Idr <[e-mail]> *On Behalf Of *Gyan Mishra
>>>> *Sent:* Thursday, January 12, 2023 3:15 PM
>>>> *To:* Robert Raszuk <[e-mail]>
>>>> *Cc:* [e-mail]
>>>> *Subject:* Re: [Idr] WG adoption call for
>>>> draft-abraitis-bgp-version-capability-08, to end September 25
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> So I think the crux of the issue is with so many open BGP flavors and
>>>> versions and running into possibilities of feature support issues, I think
>>>> it would be very helpful to be able to see the compute nodes bgp version
>>>> from the TOR for troubleshooting.  In case their are known bugs with
>>>> certain versions.
>>>>
>>>>
>>>>
>>>> So if you were able to do a “show BGP summary” and are able to see the
>>>> versions would be helpful.
>>>>
>>>>
>>>>
>>>> Kind Regards
>>>>
>>>>
>>>>
>>>> Gyan
>>>>
>>>>
>>>>
>>>> On Thu, Jan 12, 2023 at 12:07 PM Robert Raszuk <[e-mail]>
>>>> wrote:
>>>>
>>>> Gyan,
>>>>
>>>>
>>>>
>>>> > I can see a lot of value in this draft
>>>>
>>>>
>>>>
>>>> So imagine you are a TOR.
>>>>
>>>>
>>>>
>>>> Could you provide some examples on what would you do differently to
>>>> compute
>>>>
>>>> nodes speaking to you from BIRD BGP vs from exaBGP vs home grown
>>>> Python BGP ?
>>>>
>>>>
>>>>
>>>> Many thx,
>>>>
>>>> R.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Jan 12, 2023 at 5:53 PM Gyan Mishra <[e-mail]>
>>>> wrote:
>>>>
>>>>
>>>>
>>>> I support the draft and agree this is very useful for cloud native
>>>> environments.
>>>>
>>>>
>>>>
>>>> I think the main use of this feature is for DC fabric extension to
>>>> compute nodes and now as well Kubernetes microservices cloud native
>>>> containerization or router in a container.
>>>>
>>>>
>>>>
>>>> Just about every router vendor and ONF disaggregation vendor has a
>>>> container version of router such as Cisco’s XRD, Juniper cRPD, SONiC,
>>>> Nokia, Arista etc which gives you both control plane and data plane to
>>>> front and provide CNI networking for K8 Kubernetes microservices.
>>>>
>>>>
>>>>
>>>> As well as you have all the Open BGP versions FRR, BIRD, Quagga, ExaBGP
>>>> etc that  give you the BGP control plane to advertise routes using Linux
>>>> data plane.
>>>>
>>>>
>>>>
>>>> https://containerlab.dev/manual/kinds/
>>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcontainerlab.dev%2Fmanual%2Fkinds%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C877a543e7c434aeecc9d08daf5f4adb6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638092728500492184%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=nOLWrbrNMQILNzVFclXgLiQZ4LQY8iUpJsOdqKozTQ8%3D&reserved=0>
>>>>
>>>>
>>>>
>>>> So this version feature is really for cloud native compute layer NFV -
>>>> VNF, CNF,  and not really for PNF  physical hardware based internet routers
>>>> or switches.
>>>>
>>>>
>>>>
>>>> I can see a lot of value in this draft and I support making a WG
>>>> document versus independent stream based on the massive proliferation of
>>>> distributed cloud native edge computing software based environments.
>>>>
>>>>
>>>>
>>>> Kind Regards
>>>>
>>>>
>>>>
>>>> Gyan
>>>>
>>>>
>>>>
>>>> On Wed, Jan 11, 2023 at 2:20 PM Robert Raszuk <[e-mail]>
>>>> wrote:
>>>>
>>>>
>>>>
>>>> > a feature that is useful from an operational standpoint
>>>>
>>>>
>>>>
>>>> So let's put all the encoding aside. Your email made me curious why
>>>> router A needs to know BGP release number, OS version and vendor name of
>>>> router B ?
>>>>
>>>>
>>>>
>>>> Are we doing such a bad job in IDR that BGP no longer interoperates at
>>>> the protocol level ?
>>>>
>>>>
>>>>
>>>> The original problem was presented as 1000s of computes reporting their
>>>> BGP versions to TORs. But those 1000s of computes are already managed by
>>>> orchestration which does have this information. Why should BGP TOR care ?
>>>>
>>>>
>>>>
>>>> Or why IXP Route Server should care that customer X is connecting with
>>>> Junos vs with Huawei vs with Arrcus to it or to other IX fabric members ?
>>>>
>>>>
>>>>
>>>> Kind regards,
>>>> R.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Idr mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/idr
>>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C877a543e7c434aeecc9d08daf5f4adb6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638092728500492184%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=prCWQdJRG0gHXfMDlKGnqMLADRUCIhJsvpRA1Hr17zA%3D&reserved=0>
>>>>
>>>> --
>>>>
>>>>
>>>> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C877a543e7c434aeecc9d08daf5f4adb6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638092728500492184%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=B5mXvFpqA4yiWAvx6Uszwt4T8ku5Wfud3feAGlawHuo%3D&reserved=0>
>>>>
>>>> *Gyan Mishra*
>>>>
>>>> *Network Solutions Architect *
>>>>
>>>> *Email [e-mail] <[e-mail]>*
>>>>
>>>> *M 301 502-1347*
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C877a543e7c434aeecc9d08daf5f4adb6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638092728500492184%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=B5mXvFpqA4yiWAvx6Uszwt4T8ku5Wfud3feAGlawHuo%3D&reserved=0>
>>>>
>>>> *Gyan Mishra*
>>>>
>>>> *Network Solutions Architect *
>>>>
>>>> *Email [e-mail] <[e-mail]>*
>>>>
>>>> *M 301 502-1347*
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C877a543e7c434aeecc9d08daf5f4adb6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638092728500492184%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=B5mXvFpqA4yiWAvx6Uszwt4T8ku5Wfud3feAGlawHuo%3D&reserved=0>
>>>>
>>>> *Gyan Mishra*
>>>>
>>>> *Network Solutions Architect *
>>>>
>>>> *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*
>>>
>>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>> *Email [e-mail] <[e-mail]>*
>>
>>
>>
>> *M 301 502-1347*
>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>>
>
>
> --
> Donatas
>