Hi Robert, Many thanks for spending time to read the draft and your comments!
If I understand the ORR and draft-varlashkin correctly, they both try to calculate (from the client's perspective) the best route that is from the client to destination/nexthop. But, just as Russ summarized, the use cases introduced in this draft (use case 1 and 2) require to calculate the route from the eBGP peer's perspective, hence to optimize the traffic flow between eBGP peers (between MANs). This seems not be solved by the ORR and draft-varlashkin. Best regards, Mach > -----Original Message----- > From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert > Raszuk > Sent: Friday, July 19, 2013 9:56 PM > To: Mach Chen > Cc: Russ White; i2rs@ietf.org; i...@ietf.org; zh...@gsta.com > Subject: Re: [i2rs] Thoughts on > draft-chen-idr-rr-based-traffic-steering-usecase > as an I2RS Use Case > > Hi Mach, > > I have read your draft. I find nothing there which is not already > solved by IDR WG document > http://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-05 > > The status of this WG document is pending two implementations. > > If you see anything technically missing in this draft possibly along > with draft-varlashkin-bgp-nh-cost-02 let's discuss. > > Best regards, > R. > > > On Wed, Jul 17, 2013 at 11:59 AM, Mach Chen <mach.c...@huawei.com> wrote: > > Hi Russ, > > > > Thanks for bringing up this discussion! > > > > Please see my reply inline... > > > > Best regards, > > Mach > > > >> -----Original Message----- > >> From: i2rs-boun...@ietf.org [mailto:i2rs-boun...@ietf.org] On Behalf Of > >> Russ > >> White > >> Sent: Monday, July 15, 2013 8:45 PM > >> To: i2rs@ietf.org > >> Cc: zh...@gsta.com > >> Subject: [i2rs] Thoughts on > >> draft-chen-idr-rr-based-traffic-steering-usecase as > an > >> I2RS Use Case > >> > >> Y'all: > >> > >> It seems, to me, that draft-chen-idr-rr-based-traffic-steering-usecase > >> might > >> provide a solid use case to add to one of our use case drafts in I2RS. The > >> basic idea is this: > >> > >> Rather than advertising multiple routes using something like add-paths to > >> optimize traffic flow between eBGP edges, why not just have the RR > advertise > >> only the route that's best from each eBGP speaker's perspective? Now, I > >> have > >> a long standing desire to see it implemented. OTOH, even if add-paths is > >> implemented, there is the issue of which set of paths to send to the RR > >> clients in any given situation. So I don't see > >> draft-chen-idr-rr-based-traffic-steering-usecase as a competitor to > >> add-paths, but rather a complimentary idea. > > > > I agree if the RR wants to advertise more than one routes to the clients. > > > >> > >> But how is the RR to know which path to send to which RR client? This is > >> where i2rs seems to fit. If the RR was attached to a controller that had > >> visibility into the layer 3 routing table at each RR client, that > >> information could be used to determine which path to send where. The RR > >> could also calculate the best path from the perspective of each RR client > > > > Yes, this is one possible way to achieve it. Alternate way is that the RR > > is the > "controller" or part of a controller, it has not only the visibility into the > layer 3 > routing table at each client, but the topology and other related information > of the > network. Then the RR can compute a path for a specific source and destination > pair, just like the traffic engineering, and then it advertises the relevant > routes to > clients though the existing route reflection mechanisms. > > > >> --but even though SPF is trivial to run, there are still problems with this > >> solution. First, you can't run SPF for a router that's not in your flooding > >> domain. Second, you can't take into account any local policies configured > >> on > >> the router you're running SPF from the perspective of. > > > > The RR and the routers/clients do not have to be in the same flooding > > domain, > the RR can establish IGP multiple adjacencies with domains (per adjacency per > domain) or use BGP-LS to collect the topology information. > > > > Regarding to the local policies, if want the RR the consider the local > > policies, > there have to be some mechanisms to collect the local policies and just > configure > it on the RR. > > > >> > >> Hence --just use i2rs to peek into the RR clients local routing table, and > >> send the client the right BGP route(s) as indicated (using add-paths to > >> include more than one path if needed, for load sharing or the like). > >> > >> This would probably fit better into the BGP use cases draft, rather than > >> the > >> one I'm co-authoring --OTOH, I thought we were merging these two into a > >> single use cases draft covering all the "first line" use cases i2rs would > >> like to cover. > >> > >> Thoughts? > >> > >> :-) > >> > >> Russ > >> > >> _______________________________________________ > >> i2rs mailing list > >> i2rs@ietf.org > >> https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
