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

["Dongjie (Jimmy)" <[e-mail]>]

> -----Original Message-----
> From: Bgp-autoconf [mailto:[e-mail]] On Behalf Of
> Warren Kumari
> Sent: Wednesday, September 2, 2020 1:04 AM
> To: Dongjie (Jimmy) <[e-mail]>
> Cc: [e-mail]; idr-chairs <[e-mail]>
> Subject: Re: [Bgp-autoconf] Move forward with bgp autoconf requirements
> and design principle
> 
> 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).

Thanks for providing the scenario, it really helps in describing the requirements.

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

On this point we probably share the same opinion, while I'd like to encourage other members to express their thoughts.

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

I agree that L3DL is a good candidate of the L2 approach, and there is also another L2 approach mentioned in the draft (LLDP based), which could provide similar functionality. It may be helpful to give some comparison of them in the design team?

Best regards,
Jie

> 
> 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]>; Randy Bush
> > > > <[e-mail]>; Robert Raszuk <[e-mail]>; 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]>; Robert Raszuk <[e-mail]>;
> > > > 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]>,
> > > 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]>; [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
> 
> --
> Bgp-autoconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bgp-autoconf