On Sat, Jan 4, 2020 at 3:46 PM Robert Raszuk <[email protected]> wrote:
> 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. > I’m good as it’s already documented in another draft. Maybe good to add as reference. > > 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. > Thanks for clarification > > >> 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 :) */ > Makes sense > > 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 :) > Agreed > > 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. > Let me know I would be happy to collaborate with you on the restart. > > Thx, > R. > > -- Gyan S. Mishra IT Network Engineering & Technology Verizon Communications Inc. (VZ) 13101 Columbia Pike FDC1 3rd Floor Silver Spring, MD 20904 United States Phone: 301 502-1347 Email: [email protected] www.linkedin.com/in/networking-technologies-consultant
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
