Re: [Bgp-autoconf] Mnutes (first pass) from 1/19/2021 Meeting of BGP Auto-conf

["Majumdar, Kausik" <[e-mail]>]

I have looked through draft-xu-idr-neighbor-autodiscovery, I think it is bit more complicated. Besides different Auto Discovery TLVs (several Hello Message TLVs), it introduces Adjacency State Machine in the BGP with so many states. This brings additional complexity in the existing BGP implementation. I am not sure if the auto discovery mechanism needs to be that complex for Data Center.

I prefer using Robert’s auto session draft as a starting point Data Center use case. This draft reuses all of the existing BGP mechanisms for auto session establishment, tries to solve the problem in a much simpler way.

Jeff, Warren, not sure if you have any initial draft for tomorrow’s discussion, I see the IETF github is empty –
https://github.com/ietf-wg-idr/draft-dt-idr-bgp-autoconf-considerations

Let’s discuss more in tomorrow’s call about the approach.

Best regards,
Kausik

From: Majumdar, Kausik
Sent: Friday, January 22, 2021 3:16 PM
To: Robert Raszuk <[e-mail]>; Jeff Haas <[e-mail]>
Cc: Linda Dunbar <[e-mail]>; Susan Hares <[e-mail]>; [e-mail]; Acee Lindem (acee) <[e-mail]>; 徐小虎(义先) <[e-mail]>; Dongjie (Jimmy) <[e-mail]>; Warren Kumari <[e-mail]>; John Scudder <[e-mail]>; Susan Hares <[e-mail]>; Jeff Tantsura <[e-mail]>; Keyur Patel <[e-mail]>
Subject: RE: Mnutes (first pass) from 1/19/2021 Meeting of BGP Auto-conf


Based on the assumption on what Robert listed below for the DC use cases – L3 connected peers and p2p links, I see most of the auto conf session setup is covered under -

draft-raszuk-idr-bgp-auto-session-setup-01

The good part of the draft, it doesn’t require any new BGP messages other than sending BGP Session Explorer packets containing standard BGP OPEN message with a multicast 224.0.0.2 address instead of a regular peer unicast address. I see this mechanism will allow to bring automated BGP session without a prior knowledge of peer AFI/SAFI.

Also, when the session is over p2p session the reachability of the endpoints are already in place. The reachability can be also done over the loopback interface as long as RIB reachability towards the source loopback resolves in a locally connected interface.

It seems this mechanism reuses all of the existing BGP mechanisms for session establishment and pretty simple solution.

If we are not concentrating to discover non directly connected peers for the DC use cases then why don’t we start the newly proposed solution based on this existing proposal.

Regards,
Kausik

From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Sent: Friday, January 22, 2021 11:43 AM
To: Jeff Haas <[e-mail]<mailto:[e-mail]>>
Cc: Linda Dunbar <[e-mail]<mailto:[e-mail]>>; Susan Hares <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Majumdar, Kausik <[e-mail]<mailto:[e-mail]>>; Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>>; 徐小虎(义先) <[e-mail]<mailto:[e-mail]>>; Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; Warren Kumari <[e-mail]<mailto:[e-mail]>>; John Scudder <[e-mail]<mailto:[e-mail]>>; Susan Hares <[e-mail]<mailto:[e-mail]>>; Jeff Tantsura <[e-mail]<mailto:[e-mail]>>; Keyur Patel <[e-mail]<mailto:[e-mail]>>
Subject: Re: Mnutes (first pass) from 1/19/2021 Meeting of BGP Auto-conf

All, If I may I have a very basic and fundamental question. If the focus and requirement is for DC - shouldn't we just focus on L3 directly connected peers ? Further more should it be a bad thing to o
External ([e-mail]<mailto:[e-mail]>)
Report This Email<https://shared.outlook.inky.com/report?id=Y29tbXNjb3BlL2thdXNpay5tYWp1bWRhckBjb21tc2NvcGUuY29tLzVjMzI0ODg4NDU4OGI4ZjRmNzBlNzAyOWE4NzllMmQwLzE2MTEzNDQ1OTkuMzQ=#key=4360fda9d6e24b8ed4f147770e70f34a>  FAQ<https://www.inky.com/banner-faq/>  Protection by INKY<https://www.inky.com>

All,

If I may I have a very basic and fundamental question.

If the focus and requirement is for DC - shouldn't we just focus on L3 directly connected peers ?

Further more should it be a bad thing to only further focus on p2p links ?

I think the moment you would like to discover non directly connected peers (with questionable use case in DC env.)  you will likely complicate the solution space significantly.

As that is related to Linda's question in a way stating it here in this thread

Thx,
R.



On Fri, Jan 22, 2021 at 8:22 PM Jeff Haas <[e-mail]<mailto:[e-mail]>> wrote:
Linda,


On Jan 22, 2021, at 2:06 PM, Linda Dunbar <[e-mail]<mailto:[e-mail]>> wrote:


[External Email. Be cautious of content]


Sue,

Thank you very much for the detailed minutes.

I hope the document will start off with what Jeff said in the meeting:
“the requirements for the elements [of data] that BGP needs to know to bring up its peering sessions.”

Then for a Data center where all wiring & boxes are trusted, the auto-configure needs much less than other scenarios.

Like what Warren said : If I do not trust the people plugging things in, then I have to do a bunch of pre-configuration on
the device before it get s plugged in and turned up. And so this has implications on how much of the
auto-configuration stuff happens by itself. How much needs the orchestration system needs to do.

The document that I'll have updated by next session will be toward the point of bgp transport-session autoconfiguration.

The design team will likely need a discussion of how much the transport mechanism needs to provide towards a client for purposes of bootstrapping the next layer for a given scenario.  Much of this can likely happen in the bgp open message... but it likely will need to happen somewhere.

The extended conversation will need to be how much of the autoconfiguration story we want to solve in IDR and elsewhere.  Even for the relatively easy scenario for a BGP Clos participant, where the device participates in the topology is a needed thing for autoconfiguration.

We'll likely find the transport auto config was the easy piece. :-)

-- Jeff

Linda

From: Susan Hares <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, January 21, 2021 10:42 PM
To: [e-mail]<mailto:[e-mail]>; Linda Dunbar <[e-mail]<mailto:[e-mail]>>; 'Majumdar, Kausik' <[e-mail]<mailto:[e-mail]>>; 'Acee Lindem (acee)' <[e-mail]<mailto:[e-mail]>>; '徐小虎(义先)' <[e-mail]<mailto:[e-mail]>>; 'Dongjie (Jimmy)' <[e-mail]<mailto:[e-mail]>>; 'Jeff Haas' <[e-mail]<mailto:[e-mail]>>; 'Warren Kumari' <[e-mail]<mailto:[e-mail]>>; 'John Scudder' <[e-mail]<mailto:[e-mail]>>; 'Susan Hares' <[e-mail]<mailto:[e-mail]>>; 'Jeff Tantsura' <[e-mail]<mailto:[e-mail]>>; 'Keyur Patel' <[e-mail]<mailto:[e-mail]>>; 'Robert Raszuk' <[e-mail]<mailto:[e-mail]>>
Subject: Mnutes (first pass) from 1/19/2021 Meeting of BGP Auto-conf

I’ve attached the minutes from the meeting in pdf form.
Let me know if you wish a text form as well.

Audio recording from meeting at: https://youtu.be/NGwomqt9MF4<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fyoutu.be*2FNGwomqt9MF4&data=04*7C01*7Clinda.dunbar*40futurewei.com*7C893e5201af1e4833b6c308d8be900cc7*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637468873197826578*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=aZTP9bTa6WRp*2FeUcFU3QX9L*2BAJheHCUwFtBFLImEzgk*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!WRepfeQ9AYJHKsSSxXU2tSp9RmDF80YfIgcl9_OLpoFhji_Ww_oDRi40wEVbl7w$>

Sue