Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Very good point Jeff - thx for bringing this one up too in this context.

One thing however in this entire thread is very blurry and mixed line
between what is useful for BGP itself and what is specifically useful for
the cases of BGP deployments in MSDCs.

The fundamental reason why Petr shared the idea of using BGP in large scale
DCs was redundant flooding reduction of native link state protocols as well
as lowest common denominator across OEM vendors supporting high speed L3
switches/routers for DC fabric.

With that let's face it .. there is perhaps only handful of MSDCs in the
world which technically still needs to use BGP as dynamic reachability
protocol. Rest of them would be much better using either:

* native link state protocols possibly with proposed by Tony Li flooding
reduction
* native link state protocols possibly with proposed by Naiming flooding
optimizations for DCs
* Russ's proposal for ISIS in openfabric
* (apologies if I missed any other work here)

and for those really brave:

* run RIFT

If folks having 10 or 100 or 1000 nodes in the spine of their DCs don't
want to feel any smaller the FB or MS or Amazon I think they are just fine
to either run BGP as is or be most advanced and support fork of BGP to be
focused on DCs - call it DC-BGP which would run different code base then
real WAN BGP optimized for small and medium data centers fabrics and would
includ use of different TCP ports. LSVR could be placed in that category.

Thx,
R.

PS, Most of configuration tasks in any well operated network is all
automated. I am missing the real practical need for any auto-configuration
or auto-discovery enhancements for real data centers where provisioning
tool is in place. Is this for Wild Wild West type of fabrics where spine or
super spine or TORs get mounted and connected at random then someone
expects that turning it on is all what is needed to improve the fabric's
bandwidth ?

On Thu, Jul 12, 2018 at 10:03 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:

> On Thu, Jul 12, 2018 at 10:35:12AM -0400, Eric C Rosen wrote:
> > There is so much overlap with the idr-lldp-peer-discovery draft that
> > I don't see how the WG could adopt both of them.  The
> > idr-neighbor-autodiscovery draft thus should not be adopted unless
> > the intention is to reject the idr-lldp-peer discovery draft. Is
> > that the intention?  I don't recall seeing much discussion comparing
> > and contrasting the two.
>
> And not contradicting any of Eric's other good points, we have other work
> happening outside of IDR that overlaps this auto discovery problem space:
>
> https://datatracker.ietf.org/doc/draft-acee-ospf-bgp-rr/
>
> Easy to say that it's a popular topic. :-)
>
> -- Jeff
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>