Subject: [Bgp-autoconf] bgp auto configuration -01 update after interim discussion

From: Jeffrey Haas <[email-masked]>
Date: Tue, 22 Jun 2021 16:32:27 -0400

Please find attached proposed updates to the auto-configuration
Internet-Draft that attempts to address the consensus discussion at this
week's IDR interim for auto configuration.

I'd like to publish this on Friday.  Your review is greatly appreciated.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 23 Jun 2021 07:47:02 +0200

Hi Jeff,

I think one thing from the list below requires a bit of clarification ...
specifically this is about AFI/SAFI list.

   BGP Session Protocol State, discovered at BGP OPEN:

   *  AS Numbers
   *  BGP Identifier
  * *  Supported AFI/SAFIs*

So I have two questions:

Q1 Assume operator needs to enable new AFI/SAFI at some point. How
would it work as far as auto discovery is concerned ?

Q2 Assume we use dynamic capabilities (only for AFI/SAFI update) how
would it work with auto discovery if at all ?

I guess the bigger question here is the scope of auto discovery.

Is auto-discovery simply bootstrap any BGP relation between peers ?

or

Is auto discovery required/to be also used in run time when adding new
AFI/SAFIs for already established session(s) ?

The reason for this is that what we are doing is essentially
duplicating AFI/SAFI from BGP OPEN which I am not sure if this is a
feature or a bug.

Lastly, how about cases where endpoints have configured potential
peering, however it is not activated in cfg. Assuming that we would
still want to signal those in autodiscovery would you send it when
enabled and not activated on a neighbor ?

Thx,
R.

On Tue, Jun 22, 2021 at 10:06 PM Jeffrey Haas <[email-masked]> wrote:

> --
> Bgp-autoconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bgp-autoconf
>

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 23 Jun 2021 09:03:35 -0400

Robert,

> would it work as far as auto discovery is concerned ?

In my opinion, it's uninvolved beyond perhaps bumping the version number in
the auto-discovery packet.

The feedback from the working group is that afi/safi is not to be contained
in those packets.  So, if you're already peering with the discovered peer,
it's no different than if there's a configuration change to an existing
session.  If you're not peering with it because the session was previously
unacceptable, the version number is bumped, the client can connect and see
if the contents of the OPEN are acceptable, and then peer - or not.

> would it work with auto discovery if at all ?

I'd consider it out of scope since it's not a deployed feature.

> duplicating AFI/SAFI from BGP OPEN which I am not sure if this is a

This information is not carried in the auto-discovery PDU.  It is learned
from connecting to the peer and learning it from the OPEN message.

If you think the text doesn't adequately explain that, please supply some
clarifying text.

> enabled and not activated on a neighbor ?

I have no idea what this might mean.

If you haven't activated it in configuration, why would the discovery
protocol advertise an endpoint is available?

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 23 Jun 2021 15:16:06 +0200

Hi Jeff,

I am referring to this slide

> in those packets.

So are you saying that AFI/SAFI will not be part of the auto discovery ?

If so I agree and all is clear.

> I'd consider it out of scope since it's not a deployed feature.

Well deployed or not the question I think is still valid. But again if we
are not to carry AFI/SAFI in AD then no issue.

> If you think the text doesn't adequately explain that, please supply some

Then I am not quite sure why do we then even talk about it ? Especially
looking at the slide it seems like this is part of AD.

BGP OPEN comes after AD.

> protocol advertise an endpoint is available?

This is part of Cisco cfg to activate AF or not.

But before spending any time on this here let's clarify if "supported
AFI/SAFIs" are part of AD messages or not.

Thx,
R.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 23 Jun 2021 10:04:36 -0400

> > The feedback from the working group is that afi/safi is not to be contained

As we discussed in the interim, slide 4 was the contents we discussed at
prior IETF 110.

Slide 5 covered the discussion that while this state is needed by the
auto-discovery procedure, the session state could be gathered from the BGP
OPEN message as "discovery at open".

It's still state for an auto-discoverying peer needs.

> So are you saying that AFI/SAFI will not be part of the auto discovery ?

Correct.

Tersely:
Auto-discovery PDUs containing sufficient information to do a BGP connection
are sent in their protocol.

A client that is receiving those auto-discovery PDUs creates and opens a BGP
session to that endpoint.  It then has the information present in the BGP
OPEN.

If the client decides that it wishes to continue peering with the discovered
endpoint (the peer is acceptable), it sends its KEEPALIVE message and
transitions to Established.

Otherwise, the peer is unacceptable, and the client tears down the session
with a NOTIFICATION message.

The remaining procedures are intended to avoid repeated connection attempts
where no progress will be made:
- The client doesn't initiate any new connections to the discovered peer
  unless its own acceptance criteria have changed for the session, or the
  version number in the auto-discovery PDU changes from the last version
  tried.
- When either changes, the process above repats.

> looking at the slide it seems like this is part of AD.

Hopefully the interim's recording will be posted and won't have the problems
many people experienced with meetecho.  The context was clear during the
interim.

However, the description above is what the consensus was.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 23 Jun 2021 15:52:49 +0200

Hey Jeff,

Ok this sounds good. I was not clear - apologies if I did not get this from
Interim.

One related and one unrelated question:

Related:

* Assume we did not reach mutually interesting AFs to establish session and
we suppressed OPENs as you said. Now if I add a new AF on either side - do
I need AD PDU or can I just try BGP OPEN as I already know the peer(s) ?

Not related:

Just like in BGP perhaps we should also support passive AD side ? Say in
leaf <--> spines or leaf <--> controller that can be perhaps useful
optimization.

Thx a lot !
R.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 23 Jun 2021 10:25:55 -0400

> I need AD PDU or can I just try BGP OPEN as I already know the peer(s) ?

OPEN messages weren't suppressed.  BGP just decided the peer was
unacceptable.  Very much like when one side requires an AFI/SAFI to be
negotiated and it didn't see it.

Consider this example:

Time 1: The client opens a session to discovered peer and does not see 
VPNv4 Unicast in the OPEN message.  It closes the session without letting it
proceed to Established.

Time 2: The discovery message indicates the version number has changed.

Time 3: The client opens a session again.  This time, it notices that the
required VPNv4 Unicast is present and considers the session acceptable.  The
session is permitted to move to Established.

> leaf <--> spines or leaf <--> controller that can be perhaps useful

That's certainly permissible in the mechanism described.  Auto-discovery
doesn't remove the need for all configuration.

If both sides select passive mode, nothing will come up.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 23 Jun 2021 16:07:21 +0200

> session is permitted to move to Established.

I meant one peer adds new SAFI in the cfg and BGP OPEN starts without any
discovery.

> If both sides select passive mode, nothing will come up.

Sorry I meant to also extend the concept of BGP passive to the
AutoDiscovery passive side. Of course each sitting on the opposite sides.

Thx,
Robert.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 23 Jun 2021 12:16:28 -0400

> I meant one peer adds new SAFI in the cfg and BGP OPEN starts without any

I think you'll need to give an explicit example of your scenario.

> AutoDiscovery passive side. Of course each sitting on the opposite sides.

In general, if you've configured your BGP Speaker to permit incoming
sessions from unknown peers, in the absence of an auto-discovery protocol we
have current status quo.  

An example of this is the Juniper "allow" stanza which permits peering from
unknown peers on a subnet. Auto-discovery is not required here.  However,
auto-discovery could be enabled in such a configuration so that client can
discover this device is running BGP and willing to peer.

-- Jeff

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 23 Jun 2021 21:25:07 +0000

I'm ok with the changes... What was the reason for removing section 2.3.2.1? 
Thanks,
Acee

On 6/22/21, 4:16 PM, "Bgp-autoconf on behalf of Jeffrey Haas" <[email-masked] on behalf of [email-masked]> wrote:

    -- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 23 Jun 2021 19:14:37 -0400

Acee, 

Extreme non consensus on the point. 

Jeff

> On Jun 23, 2021, at 5:51 PM, Acee Lindem (acee) <[email-masked]> wrote:
>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 24 Jun 2021 17:02:22 +0000

The discussion can be more productive if we can explicitly name the  operational trust models described in the Section 3.6.  

For example: 

Trusted Physical Protection:  refers to DCs that  have very strict physical protection of the datacenter, and  their deployment model assumes that anything which plugs into devices in the datacenter is, by definition, trusted.  

Not-Fully-trusted:
a) Using BGP Autoconf to perform validation of data center fabric: ...
b) 

It doesn't make much sense to compare the Auto configuration for the "Trusted Physical Protection" DC with the Auto-config for a) or b) under the Not-Fully-Trusted.

My two cents, 

Linda Dunbar

-----Original Message-----
From: Bgp-autoconf <[email-masked]> On Behalf Of Jeffrey Haas
Sent: Tuesday, June 22, 2021 3:32 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Bgp-autoconf] bgp auto configuration -01 update after interim discussion

Please find attached proposed updates to the auto-configuration Internet-Draft that attempts to address the consensus discussion at this week's IDR interim for auto configuration.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 24 Jun 2021 15:18:36 -0400

Linda,

Warren crafted this text.  Let's see what his thinking here is.

-- Jeff

> On Jun 24, 2021, at 1:02 PM, Linda Dunbar <[email-masked]> wrote:
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 25 Jun 2021 15:52:29 +0000

Hi Jeff,

Thanks for the update, most of the changes in this updated version look good to me. 

While since I didn't catch all the discussion at the interim due to poor network quality, I'd like to know whether there was some consensus about the version number part. Thanks. 

Best regards,
Jie

> From: Bgp-autoconf [mailto:[email-masked]] On Behalf Of
> Jeffrey Haas
> Sent: Wednesday, June 23, 2021 4:32 AM

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 25 Jun 2021 13:49:50 -0400

Jie,

> While since I didn't catch all the discussion at the interim due to poor network quality, I'd like to know whether there was some consensus about the version number part. Thanks. 

I think we have consensus on something like a version number.  The exact
name and semantics will likely require some text, but I think the intent is
pretty clear:

if (last_heard_number != last_remembered_number) {
	connect_again();
}

-- Jeff

---

From: Warren Kumari <[email-masked]>
Date: Fri, 25 Jun 2021 14:39:41 -0400

> Warren crafted this text.  Let's see what his thinking here is.

The majority of the text around the "different trust models" section
in "Operational Trust Considerations" is to provide some background
and level-setting.
The summary is:
1. Some operators are very trusting -- they will trust anything that
is plugged into a port (they trust their physical security, they trust
protocols to just work, they trust their employees to always plug the
right wires into the right ports, etc).
2. Some operators are more paranoid -- they design to be as robust as
possible. They will build all configs statically, they minimize trust
in the protocols to do magic, etc.
3. Some operators will take the "trust but verify" approach -- they'd
be interested in seeing how something like autoconf would work - they
will build static configs, but would like to validate these
configurations by seeing what an autoconf protocol would do. If
they've manually made a peering between sw17 port 7 and sw42 port 17 ,
but autoconf says that it wants to build a peering between sw17 port 7
and sw99 port 48, then a: autoconf is broken or b: port 7 on switch 17
is probably miswired...
4: Some operators don't want to worry about any of this stuff - they
just want to plug things in arbitrarily and have the network/autoconf
figure everything out.

Linda is right - when we talk about design assumptions, we should be
explicit about which of these trust models we are meaning -- I suspect
that, at least in the beginning, model 3 will be very common. Existing
datacenter operators will enable autoconf in some sort of "tell me
what you would do here" mode, and confirm that the sessions that
autoconf would bring up match what is actually deployed and in
operation. Assuming that autoconf gets things right, they may move
from using autoconf as a validation / debugging tool to trusting it as
the main way of bringing up sessions.

W

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra

---

From: Warren Kumari <[email-masked]>
Date: Fri, 25 Jun 2021 17:01:03 -0400

On Fri, Jun 25, 2021 at 2:39 PM Warren Kumari <[email-masked]> wrote:
> explicit about which of these trust models we are meaning

... and as a quick followup, I believe that this is simply something
for us to keep in mind when discussing solutions, etc, and nothing
that needs to change in the draft.
Please correct me if I'm missing something....
W

>  -- I suspect