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

[Jeff Haas <[e-mail]>]

Robert,


On Jan 25, 2021, at 12:18 PM, Robert Raszuk <[e-mail]<mailto:[e-mail]>> wrote:


[External Email. Be cautious of content]


Hi Jeff,

L3 directly connected means staying on the subnet :) That can be p2p (fabric side) or p2mp (compute side).

Note that https://tools.ietf.org/html/draft-raszuk-idr-bgp-auto-session-setup-01<https://urldefense.com/v3/__https://tools.ietf.org/html/draft-raszuk-idr-bgp-auto-session-setup-01__;!!NEt6yMaO-gk!XhSKvc6c3VBU44HVGO3wV9qP7nqXzVhYNbMU_0983QPrGZZJ83x4TkPdF7ctEdM$> just uses multicast group for this "local" discovery and we are done :)

If you want to stay strictly to something on the same wire, it won't help though.  I.e. prevent plugging into switches, etc.

In any case, the feedback I'll take readily from this is "scoping matters".  The discussion being what a given party thinks is acceptable for that scoping.

draft-xu also uses multicast.

-- Jeff


Best,
R.

On Mon, Jan 25, 2021 at 5:48 PM Jeff Haas <[e-mail]<mailto:[e-mail]>> wrote:
Robert,

Keeping in mind my prior comments that part of listing what the properties are is so that we can include or exclude stuff for a given domain solution, I'll offer you this:

I agree with you.

What exactly does a L3 directly connected peer mean?
And given that the link plumbing of choice for most people right now looks like Ethernet, what does "p2p" mean?

Offering my first pass at those two, I think Ethernet as p2p is effectively something we can't distinguish.  At best, it means you expect to find a single MAC at the end of the link.

At L3, that also potentially means that you have subnet properties that are palatable.  For ipv4, a /30 or /31.  For ipv6 a /127, probably on fe80::

People are obviously deploying this way.  More than a few are also doing BGP configuration by saying "use this link" without address properties and relying on the above example properties to do the end-point "discovery" work.

-- Jeff


On Jan 22, 2021, at 2:43 PM, Robert Raszuk <[e-mail]<mailto:[e-mail]>> wrote:


[External Email. Be cautious of content]


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