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

From: "Susan Hares" <[email-masked]>
Date: Thu, 21 Jan 2021 23:41:38 -0500

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://youtu.be/NGwomqt9MF4

Sue

---

From: Jeff Haas <[email-masked]>
Date: Fri, 22 Jan 2021 14:29:10 +0000

Thanks for the minutes, Sue.

I do recommend that notes stay in text, or text markup form.

You can't necessarily grep pdf.

-- Jeff

On Jan 21, 2021, at 11:41 PM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:

[External Email. Be cautious of content]

Audio recording from meeting at: https://youtu.be/NGwomqt9MF4<https://urldefense.com/v3/__https://youtu.be/NGwomqt9MF4__;!!NEt6yMaO-gk!U5BPLYD_JksRZr9AkPhHRb9r06oysQ5K-E55eA50sz4-jK8htkTPI64bZ10ti_s$>

Sue
<BGP-autoconf-jan-19-2021-meeting.pdf>

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 22 Jan 2021 19:06:15 +0000

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.

Linda

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

Audio recording from meeting at: https://youtu.be/NGwomqt9MF4<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>

Sue

---

From: Jeff Haas <[email-masked]>
Date: Fri, 22 Jan 2021 19:21:42 +0000

Linda,

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

Sue,

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

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

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 22 Jan 2021 09:40:27 -0500

Jeff:

I’ll put these in a mark-up form (xml) later today. 

Thanks, 

Sue 

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

-- Jeff

On Jan 21, 2021, at 11:41 PM, Susan Hares <[email-masked]> wrote:

 

Audio recording from meeting at:  <https://urldefense.com/v3/__https:/youtu.be/NGwomqt9MF4__;!!NEt6yMaO-gk!U5BPLYD_JksRZr9AkPhHRb9r06oysQ5K-E55eA50sz4-jK8htkTPI64bZ10ti_s$> https://youtu.be/NGwomqt9MF4

Sue

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 22 Jan 2021 20:43:03 +0100

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 <[email-masked]> wrote:

> Linda,
>
>
> On Jan 22, 2021, at 2:06 PM, Linda Dunbar <[email-masked]>
> wrote:
>
>
> *“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.
>
> *From:* Susan Hares <[email-masked]>
> *Sent:* Thursday, January 21, 2021 10:42 PM
> *To:* [email-masked]; Linda Dunbar <[email-masked]>;
> 'Majumdar, Kausik' <[email-masked]>; 'Acee Lindem (acee)' <
> [email-masked]>; '徐小虎(义先)' <[email-masked]>; 'Dongjie
> (Jimmy)' <[email-masked]>; 'Jeff Haas' <[email-masked]>; 'Warren
> Kumari' <[email-masked]>; 'John Scudder' <[email-masked]>; 'Susan
> Hares' <[email-masked]>; 'Jeff Tantsura' <[email-masked]>; 'Keyur
> Patel' <[email-masked]>; 'Robert Raszuk' <[email-masked]>
> *Subject:* Mnutes (first pass) from 1/19/2021 Meeting of BGP Auto-conf
>
> *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
>
>
>

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 22 Jan 2021 14:18:57 -0800

I’d support Robert approach, this would limit the scope and simplify the solution, perhaps being more clear on the focus on underlay, IGP/iBGP case is separate
In most cases - non directly connected neighbors  are for overlay ones and are secondary.

Cheers,
Jeff
On Jan 22, 2021, 11:43 AM -0800, Robert Raszuk <[email-masked]>, wrote:
> If the focus and requirement is for DC - shouldn't we just focus on L3 directly connected peers ?
>
> 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 Jan 22, 2021, at 2:06 PM, Linda Dunbar <[email-masked]> wrote:
> > > >
> > > >
> > > > Audio recording from meeting at: https://youtu.be/NGwomqt9MF4
> > > >
> > > > Sue
> > >

---

From: "Majumdar, Kausik" <[email-masked]>
Date: Fri, 22 Jan 2021 23:15:39 +0000

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 <[email-masked]>
Sent: Friday, January 22, 2021 11:43 AM
To: Jeff Haas <[email-masked]>
Cc: Linda Dunbar <[email-masked]>; Susan Hares <[email-masked]>; [email-masked]; Majumdar, Kausik <[email-masked]>; Acee Lindem (acee) <[email-masked]>; 徐小虎(义先) <[email-masked]>; Dongjie (Jimmy) <[email-masked]>; Warren Kumari <[email-masked]>; John Scudder <[email-masked]>; Susan Hares <[email-masked]>; Jeff Tantsura <[email-masked]>; Keyur Patel <[email-masked]>
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 ([email-masked]<mailto:[email-masked]>)
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,

Thx,
R.

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

Sue,

-- Jeff

Linda

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

---

From: Jeff Haas <[email-masked]>
Date: Mon, 25 Jan 2021 16:48:11 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

All,

Thx,
R.

Sue,

-- Jeff

Linda

Sue

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 25 Jan 2021 18:18:55 +0100

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 just
uses multicast group for this "local" discovery and we are done :)

Best,
R.

On Mon, Jan 25, 2021 at 5:48 PM Jeff Haas <[email-masked]> 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.
>
> 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 <[email-masked]> wrote:
>
>
>> 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*
>> 'Majumdar, Kausik' <[email-masked]>; 'Acee Lindem (acee)'
>> <[email-masked]>; '徐小虎(义先)' <[email-masked]>; 'Dongjie

---

From: Jeff Haas <[email-masked]>
Date: Mon, 25 Jan 2021 18:46:06 +0000

Robert,

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

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 <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

I agree with you.

-- Jeff

All,

Thx,
R.

Sue,

-- Jeff

Linda

Sue

---

From: "Majumdar, Kausik" <[email-masked]>
Date: Mon, 25 Jan 2021 23:40:33 +0000

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 <[email-masked]>; Jeff Haas <[email-masked]>
Cc: Linda Dunbar <[email-masked]>; Susan Hares <[email-masked]>; [email-masked]; Acee Lindem (acee) <[email-masked]>; 徐小虎(义先) <[email-masked]>; Dongjie (Jimmy) <[email-masked]>; Warren Kumari <[email-masked]>; John Scudder <[email-masked]>; Susan Hares <[email-masked]>; Jeff Tantsura <[email-masked]>; Keyur Patel <[email-masked]>
Subject: RE: Mnutes (first pass) from 1/19/2021 Meeting of BGP Auto-conf

Regards,
Kausik

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

All,

Thx,
R.

Sue,

-- Jeff

Linda

Sue

---

From: Jeff Haas <[email-masked]>
Date: Tue, 26 Jan 2021 04:00:30 +0000

I'm tardy on the work.  I've pushed the document to date to the repo seconds ago.

Thus far I've done some scrubbing on the prelude text.  I was about to start incorporating my notes from the various proposals and our prior sessions.  I may get a bit more of this done by tomorrow's session.

-- Jeff

On Jan 25, 2021, at 6:40 PM, Majumdar, Kausik <[email-masked]<mailto:[email-masked]>> wrote: