Gyan, I noticed in the document there is a mention in the beginning of the draft > regarding “best-external” but the detailed use of that knob is not > documented as part of BGP PIC edge functionality. >
It does not need to be documented. Section 2.1.2 just makes is clear that to use BGP PIC you need more paths. How you organize your BGP such that multiple paths are present is beyond the scope of this draft. I noticed that the router reflector critical functions of selecting all > paths and advertising additional paths is not mentioned which is critical > for BGP PIC operation. > Use of route reflection is just a way to distribute your BGP paths. It is not a necessity. Moreover RRs if deployed well do not select bgp paths based on their view of IGP metric. Hint: Pls look at Optimal Route Reflection draft. > Another critical feature to mention in the draft related to route > reflector and BGP PIC edge functionality is that for L3 VPN vpnv4 and vpnv6 > the route reflector is not able to advertise all paths as with IPv4 and > IPv6.. Workaround to this issue is that the RD must be unique for each PE > within the VPN > Unique RD per VRF is not a workaround. It is best practice for years now. Number of implementations allocate RDs by default (auto-rd) per VRF. Other deployments do it properly via NMS. > Also mention that PIC edge can be used independently of PIC core however > in most cases PIC core if the platform supports is enabled by default. PIC > edge can be configured even if PIC core is not supported on the hardware > platform and would still improve convergence. > That would be a bit stating the obvious :) We should also I think mention NHT next hop tracking FIB watcher and > basically part of using the hierarchal fib is similar to NHT feature > tracking the next hop PE exit points that correlate to all BGP NLRI from > the exit point. For hardware platforms that don’t support hierarchical fib > that NHT can be used as a workaround to achieve the same convergence. > NHT and hierarchical FIB are completely orthogonal features. First is responsible to detect the failure via watching RIB updates (registers next hops and get's callback when IGP deletes or modifies it) while latter is part of the repair mechanism. There is nothing "similar" between those two features. Also note that for PIC Core to really be beneficial that the IGP timers > must be optimized as well as use of IP LFA, R-LFA for ldp and BFD should be > configured to optimize next hop convergence. > 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. > Should also be noted that if exit point PEs edge uses BGP next-hop-self ; > next hop rewrite to loopback ; the loopback never goes down even if PE-CE > failure occurs and that can impact overall convergence and this issue > exists for both MPLS and IP core scenario. > I am trying to develop a workaround for this issue but have not found a > solution yet. > We solved this problem over 11 years ago by defining new Edge_Discriminator attribute. However the draft was not progressed due to lack of real interest and easy workaround of not setting next hop self. https://tools.ietf.org/html/draft-pmohapat-idr-fast-conn-restore-03 Thx, Robert.
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
