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

On Fri, Jun 25, 2021 at 2:39 PM Warren Kumari <warren@kumari.net> wrote:
>
> 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

... 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
> 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

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