Re: [Bgp-autoconf] Move forward with bgp autoconf requirements and design principle

[Warren Kumari <[e-mail]>]

On Tue, Sep 1, 2020 at 5:53 AM Dongjie (Jimmy) <[e-mail]> wrote:
>
> Hi Warren,
>
> Thanks a lot for your mail and suggestion.
>
> Since we didn't submit either draft before IETF 108 cut-off, we didn't get a slot on the IDR agenda. While as mentioned in the chairs' slides, there could be interims for BGP autoconf before next IETF meeting.
>
> I also agree that draft-bgp-discovery-layers provides good summary of the consensus we had reached, and draft-dt-idr-bgp-autoconf-considerations was an attempt to collaborate based on that draft (by reordering some paragraphs, adding considerations about design principles, and covering other candidate solutions discussed in the design team.) It seems we did't reach consensus in the design team on those modifications, in that case I'm happy to fall back to draft-bgp-discovery-layers and start again from that.
>
> To move forward, perhaps we could continue the discussion on "design principles". In Randy's draft, the mechanisms are classified by network layers they reside in, thus some discussion about the pros and cons of the mechanisms in each layer may be helpful, and the output may be incorporated in the draft. If we can reach some consensus about the suitable layer(s) for discussion, then perhaps the discussion about the candidates in that layer could be the next step?


So, in my ideal world / scenario, I pick up a switch from a pile of
switches, walk onto a datacenter floor, and plug it in. It probably
has some initial config via DHCP/similar, and then starts listening
for BGP peers.

It discovers that on ports 1,3 and 17 there are some Autoconf_BGP
speakers, with IPv4 addresses X4, Y4, Z4, and IPv6 addresses X6, Y6,
Z6. Ideally each of these interfaces also have some sort of "tag" like
"I'm a leaf" or "I'm a spine, and a DC edge-node". If the switch has
some initial config, it checks if the AS number and authentication
matches (and, possibly, if the tags seem sane), and then brings up
BGP. The connected interface info should allow me to login and do some
sort of show command[0] to confirm that these interfaces connect where
I expect (and if not, I can go figure out what cables got messed up
where).

To my mind the "L2" model is the obvious starting point -- if I've got
everything working at L3, why am I bothering to automate this last
tiny part?
L3DL (draft-ietf-lsvr-l3dl-ulpc) gives me basically everything I need
-- it's not yet implemented on all my devices, but, then again,
neither is bgp-autoconf (and the longer we navel-gaze[1], the longer
this will be true...)

W
[0]: Yes, yes, probably actually using
yang/netconf/snmp/opensomething/st/smoke-signals, but the concept
remains the same...
[1]: https://www.urbandictionary.com/define.php?term=navel-gazing

>
> Thoughts?
>
> Best regards,
> Jie
>
> > -----Original Message-----
> > From: Warren Kumari [mailto:[e-mail]]
> > Sent: Tuesday, September 1, 2020 4:24 AM
> > To: Dongjie (Jimmy) <[e-mail]>
> > Cc: [e-mail]
> > Subject: Re: [Bgp-autoconf] Move forward with bgp autoconf requirements and
> > design principle
> >
> > Hi all,
> >
> > I must admit that I seem to have lost track of what's going on - I got distracted
> > by $dayjob, and IDR @ IETF108 conflicted with mboned, but I didn't see this on
> > the agenda or minutes or a report in shares' WG Status report.
> >
> > I had thought that Randy's document
> > (https://git.rg.net/randy/draft-bgp-discovery-layers) provided a really good
> > summary of what *I* had thought we had decided. I've looked at
> > draft-dt-idr-bgp-autoconf-considerations, but found it much harder to read, and,
> > other than referencing other documents in 5.2.2,
> > 5.2.3 I'm not sure what it adds...
> >
> > So, can someone help me swap state back in? Where are we? It feels like we've
> > stalled...
> >
> > I propose:
> > 1: We go back to draft-bgp-discovery-layers as a starting point
> > 2: Discuss what L3DL *doesn't* do[0], and, if there really is something
> > 3: choose another option, discuss what it doesn't do, and repeat this until we
> > get somewhere...
> >
> > Or, did the DT die and I just missed the email?
> > W
> >
> >
> > [0]: I'll note that I like L3DL - it's got a good security story, it provides / can
> > provide all of the info we need, it's simple, etc.
> >
> >
> > W
> >
> > On Thu, Jul 9, 2020 at 12:44 PM Dongjie (Jimmy) <[e-mail]>
> > wrote:
> > >
> > > Hi all,
> > >
> > >
> > >
> > > As promised please find attached an updated version of the draft. I changed
> > the draft title a little bit to better reflect the content and purpose. Thanks again
> > to Randy for his effort on the initial version.
> > >
> > >
> > >
> > > The design principles are listed in section 4 for further discussion. Some
> > description about the candidate approaches draft-xu and draft-raszuk are added.
> > The rest are some editorial changes.
> > >
> > >
> > >
> > > Please review this document and provide your comments and suggestions,
> > proposing text would be better. Note that the authorship and contributor of the
> > design team document would be based on the contribution.
> > >
> > >
> > >
> > > Although it may be quite challenging to get the draft ready before the
> > submission cut-off, depending on the progress we made, perhaps we could have
> > an -00 version first, then have it further revised before the meeting.
> > >
> > >
> > >
> > > Many thanks,
> > >
> > > Jie
> > >
> > >
> > >
> > > From: 徐小虎(义先) [mailto:[e-mail]]
> > > Sent: Thursday, July 9, 2020 9:47 AM
> > > To: Bgp-autoconf <[e-mail]>rg>; Randy Bush
> > > <[e-mail]>om>; Robert Raszuk <[e-mail]>et>; Dongjie (Jimmy)
> > > <[e-mail]>
> > > Cc: [e-mail]
> > > Subject: Re: [Bgp-autoconf] Move forward with bgp autoconf
> > > requirements and design principle
> > >
> > >
> > >
> > > +1
> > >
> > >
> > >
> > > ------------------------------------------------------------------
> > >
> > > From:Jeff Tantsura <[e-mail]>
> > >
> > > Send Time:2020年7月9日(星期四) 02:02
> > >
> > > To:Randy Bush <[e-mail]>om>; Robert Raszuk <[e-mail]>et>;
> > > Dongjie (Jimmy) <[e-mail]>
> > >
> > > Cc:[e-mail] <[e-mail]>
> > >
> > > Subject:Re: [Bgp-autoconf] Move forward with bgp autoconf requirements
> > > and design principle
> > >
> > >
> > >
> > > Jie,
> > >
> > > Sounds good, I don’t really see any convergence yet, so unbiased
> > > summary would be a great start
> > >
> > >
> > >
> > > Cheers,
> > >
> > > Jeff
> > >
> > > On Jul 8, 2020, 8:47 AM -0700, Dongjie (Jimmy) <[e-mail]>om>,
> > wrote:
> > > Hi Randy and all,
> > >
> > > It is good we agreed on the scope of this document is DC. Certainly in the
> > design team we can analyze and discuss the difference between the design for
> > DC and WAN, my understanding is the details about it does not belong to this
> > document.
> > >
> > > Coming back to the preparation of the draft deliverable, in addition to revising
> > the existing text in the draft, my suggestion is to also add some brief description
> > about each candidate solution regarding the functions, extensibility, etc., this
> > may be similar to what was presented in the slides to the WG in last IETF
> > meeting. I will work on some text and provide an update tomorrow. Any
> > contribution to this is welcome.
> > >
> > > As for the design principle (including which layer the protocol should be based
> > on and the interaction with BGP), if we cannot reach agreement before the
> > meeting, probably we could provide a summary of the considerations first, and
> > ask for some feedbacks from the WG. Thoughts?
> > >
> > > Best regards,
> > > Jie
> > >
> > > -----Original Message-----
> > > From: Randy Bush [mailto:[e-mail]]
> > > Sent: Monday, July 6, 2020 11:53 PM
> > > To: Robert Raszuk <[e-mail]>
> > > Cc: Dongjie (Jimmy) <[e-mail]>om>; [e-mail]
> > > Subject: Re: [Bgp-autoconf] Move forward with bgp autoconf
> > > requirements and design principle
> > >
> > > The draft in question specifically adds WAN auto conf.
> > >
> > > that was certainly not the intent; and it's not really there in the
> > > words.. on the other hand, if we should keep an eye on the WAN as we
> > > design the LAN, we should be aware of choices which might
> > > unnecessarily restriict ourselves next year.
> > >
> > > Then the L3 peer auto discovery is just deferred to
> > > draft-ietf-lsvr-l3dl
> > >
> > > also not intended. i did ask for your help stitching multicast in, and
> > > you declined. perhaps you have time now.
> > >
> > > However reading thorough draft-ietf-lsvr-l3dl it is clear that it is
> > > not applicable to WAN.
> > >
> > > it is not applicable to many things :)
> > >
> > > as i said at the beginning, i do not think l3dl is really a serious candidate here.
> > > otoh, we would be silly if we did not keep an eye to see if there are
> > > lessons to be learned from it.
> > >
> > > [ fwiw, i think the scalability added to lsoe to become l3dl was not
> > > worth the complexity. but that is a discussion for another universe ]
> > >
> > > randy
> > >
> > > --
> > > Bgp-autoconf mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/bgp-autoconf
> > >
> > > --
> > > Bgp-autoconf mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/bgp-autoconf
> >
> >
> >
> > --
> > I don't think the execution is relevant when it was obviously a bad idea in the
> > first place.
> > This is like putting rabid weasels in your pants, and later expressing regret at
> > having chosen those particular rabid weasels and that pair of pants.
> >    ---maf



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf