Hi Robert, et al, Great question!!! I want to assure the WG that Robert and I have had no prior collusion and he asked this independently…
From: <[email protected]<mailto:[email protected]>> on behalf of Robert Raszuk <[email protected]<mailto:[email protected]>> Date: Wednesday, January 25, 2017 at 5:20 PM To: Acee Lindem <[email protected]<mailto:[email protected]>> Cc: Uma Chunduri <[email protected]<mailto:[email protected]>>, Routing WG <[email protected]<mailto:[email protected]>> Subject: Re: Routing in DC RTGWG interim - updated Hi AC, My point was to indicate that running SPF regardless if it happens in central controller or at each switch would be perhaps fine as a add-on not as replacement of basic 7938. As simple as this. Please think about it :) IMHO such positioning is a smoothest way to move forward. And if someone later thinks that BGP-SPF is cool and works great they can at their will decommission vanilla 7938. But this should be an option to the user and BGP-SPF architecture should be written from day one with a notion of augmentation not a clean slate proposal. We have thought about that. The beauty of BGP SPF is that you can use it solely for the underlay and maintain the services (e.g., RFC 4364) in the overlay. Additionally, it is very easy to migrate only a portion of your data center to BGP SPF. Routers operating in both domains (BGP SPF and RFC 7938) can perform the interworking by advertising AF IPv4 unicast routes into the BGP-SPF domain as BGP-LS Prefix NLRI and reachable BGP-SPF prefixes into the normal BGP IPv4 or IPv6 unicast domain as reachable NLRI. Thanks, Acee Cheers, R. On Wed, Jan 25, 2017 at 11:09 PM, Acee Lindem (acee) <[email protected]<mailto:[email protected]>> wrote: Hi Robert, From: rtgwg <[email protected]<mailto:[email protected]>> on behalf of Robert Raszuk <[email protected]<mailto:[email protected]>> Date: Wednesday, January 25, 2017 at 4:34 PM To: Uma Chunduri <[email protected]<mailto:[email protected]>> Cc: Routing WG <[email protected]<mailto:[email protected]>> Subject: Re: Routing in DC RTGWG interim - updated I am not sure this is the central issue ..but for SPF based approaches to have the topology view this could be one part of it (and hence in bgp-spf, usage of BGP-LS to advertise the TCP peering as a Link NLRI with new TLVs distinguishing itself from IGP adj representation). Well on BGP SPF proposal I see number of advantage .. but very honestly I do not buy into how it is being "sold" here. If folks talking about it would say ... our proposal is to run BGP SPF on controller only to optimize and augment things while you still run normal eBGP in CLOS I would be perhaps very interested in seriously supporting this work. But if I hear that this is to replace eBGP and push routes left and right "centrally computed" this goes way over the max level of gain vs drawback/risk level one is to accept. We are really not intending the controller deployment to follow either of the above. The SPF route computation is distributed in each BGP switch and hierarchal reflectors are used to allow for a spare mesh of BGP sessions. This overcomes the many copies issue that Tony alluded to when BGP is used for <key, value> distribution. The controller or route reflectors (dependent on the use case) could subset the scoping on the BGP-LS information or inject NLRI to influence the SPF. My fellow authors can chime in as well. Thanks, Acee Best, R.
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
