Hi Gyan, I was referring to the best-external flag operation and how that feature > works as far as advertisements of backup paths. Not necessarily the > organization of multiple paths. >
Best external is covered already in https://tools.ietf.org/html/draft-ietf-idr-best-external-05 Honestly I am not sure what "flag" are you referring to. Glad to see the draft and I agree keeping the state centralized is a > better design strategy then pushing state to the edge. Also lends itself > to a centralized controller based model. > > >> https://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-19#page-6 >> > I think it would be good not to mix two things. Optimal reflection chooses N optimal paths for given client and group of clients. Those for PIC to work still need to be distributed to the edges in any network which uses encapsulation. For networks using IP lookup based routing BGP PIC can be used on ABRs possibly also acting as physical or virtual RRs. > I agree RD auto has been a best practice for years. I was just > pointing out that if RD auto is not employed that the issue will present > itself. Something to be cognizant of which is why I mentioned. > Great that we seems to agree on RD best practice. Again for this draft ie BGP PIC to be able to work redundant paths must be present. /* We considered just sending multiple next hops for non VPN use cases effectively also allowing to construct bundle rewrites with BGP PIC, but then add-paths came as "the solution" which overruled alternatives :) */ Sorry - no. PIC can work fine without IGP too just using BGP recursive next >> hops. Use of any flavour of LFA helps to quickly restore connectivity to a >> given next hop - it is completely orthogonal to BGP PIC feature. >> > > Understood. I was just stating for “optimal” convergence > recommendation which I thought was relevant since using BGP PIC is an > “optimization” to that end in achieving as close to hitless convergence. > Your point is sound and indeed many networks (or vendors) today do not even employ basic IGP or BGP PIC. In fact many folks still care about speed of IGP or BGP *convergence* instead of focusing on fast connectivity restoration objective leaving protocols in peace allowing them to converge at their own pace. But I don't think that current draft in question is the best place for such education :) I found that draft when I was researching and wondered why it didn’t > progress. I do think it has a lot of merit. Major point being that if you > don’t do the next hop self and advertise you external links now imagine > with millions of peers your LFIB FEC binding state becomes unmanageable. I > am all for resurrection of the draft and I would support. > Well I do not know any network with millions of peers :) But I am always open to learn ! Said this I do still see some value in moving fwd with this draft. If other think this is useful we could restart this as a separate IDR/GROW thread. Thx, R.
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
