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
