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

Occur with Jeff. there are still many MSDCs which will continue to use RFC7938 for a long while. BGP neighbor discovery mechanism is a needed feature in that case.

Best regards,
Xiaohu

------------------------------------------------------------------
From:Jeff Tantsura <jefftant.ietf@gmail.com>
Send Time:2018年7月13日(星期五) 09:59
To:Robert Raszuk <robert@raszuk.net>
Cc:Jeffrey Haas <jhaas@pfrc.org>; Eric C Rosen <erosen@juniper.net>; idr wg <idr@ietf.org>; draft-xu-idr-neighbor-autodiscovery <draft-xu-idr-neighbor-autodiscovery@ietf.org>; Susan Hares <shares@ndzh.com>
Subject:Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Run RIFT it is!!!
 (Sorry, I’m biased ;-))
From my personal experience - most mid size guys are either running BGP in the underlay already or looking forward to moving to it.
They do need AD functionality, and the proposal being discussed is trying to provide  the solution.

Regards,
Jeff

On Jul 12, 2018, at 14:34, Robert Raszuk <robert@raszuk.net> wrote:

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