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

On Thu, Jun 24, 2021 at 3:18 PM Jeffrey Haas <jhaas@pfrc.org> wrote:
>
> Linda,
>
> 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

> -- Jeff
>
>
>
> > On Jun 24, 2021, at 1:02 PM, Linda Dunbar <ldunbar@futurewei.com> wrote:
> >
> > 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 <bgp-autoconf-bounces@ietf.org> On Behalf Of Jeffrey Haas
> > Sent: Tuesday, June 22, 2021 3:32 PM
> > To: bgp-autoconf@ietf.org
> > Cc: idr-chairs@ietf.org
> > 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.
> >
> > I'd like to publish this on Friday.  Your review is greatly appreciated.
> >
> > -- Jeff
> >
> > --
> > Bgp-autoconf mailing list
> > Bgp-autoconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/bgp-autoconf
>

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