Hi Aijun, > > Yes BGP option 2 as I described gives you PIC effect. In fact I am quite > convinced that if done right it can be much faster then IGP flooding > especially at scale. Please recall all safety belts build into IGP to slow > down churn when multiple events happens in a time scale. That will have a > negative effect on PUA/PULSE propagation speed at scale. > > [WAJ] If such thing happen, won’t the BGP update will also be affected? > The underlying IGP are converging. >
You need to be able to distinguish local area convergence from hierarchical domain wide churn. No BGP will not be affected at all neither in the local area nor in any other area. [WAJ] When you recall the NH prefix, the 32/ or 128/ route is not exist > within the RIB of receiving node, only the summary routes from IGP is > existing. How to prefer the 32/ or /128 route? > In Option-2 I suggested it does exist. > [WAJ] Even with this non existing assumption, you will require the ABR to > be configured with other PE for BGP sessions. Such design will let each ABR > act again as RR, won’t you think it is redundant? > No. What you have envisioned would be a pretty ugly design. In Option-3 I proposed ABR will just have 2 sessions to area-0/level-2 RRs (current or new). [WAJ] Register with Loc RIB is easy, but register with other node within > IGP is not easy. There is currently no such mechanism within IGP, as Tony > Li also confirmed. > Well there is at least one registration mechanism today with BGP where PE registers with RRs on what is interesting for it. Check out RFC4684. [WAJ] The tunneled traffic will be diverted to other backup tunnel until > the primary node is back again. The detection of the UP status of the > primary node is depend on the tunnel technology itself. PUA/PULSE just > notifies the tunnel endpoint is down. > Encapsulation does not require tunnel setup. Hint: MPLS over UDP. Show me please where is the "tunnel" ? [WAJ] Using the backup tunnel until the primary node is brought up again. > :) Thx, R. >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
