Aijun, AJ] For your proposed BGP solutions, Peter has responded you and I agree > with his opinions with the followings additional comments: >
All Peter keeps saying is that the solution must work where BGP is non existent. I question whether BGP in any network is non-existent. . > [Option 1]: Can’t get the PIC effect. We should track the reachability of > BGP NH. > 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. > [Option 2]: Even you tell the remote PE via BGP that it’s peer is down, > but the IGP is still telling him reachable. Will it puzzle the receiving > node? > No. Not at all. Decent BGP implementation has a knob where you select over which length of next hop should be used to resolve service routes. So if you specify to resolve over /32 or /128 the presence of summary routes in IGP will not affect it. > [Option 3] BGP-LS is mainly used for transferring the topology information > northbound to controller, we seldom use it to distribute topology > information within the underlying network itself. This is IGP’s work. > Oh so now we are talking about topology information distribution ? Each email from you brings a new surprise :) In any case BGP-LS was just an example of a SAFI. It would be ok to define a new SAFI for it. Or even easier, use 1/1 or 2/1. No one (well at least not me) would recommend any form of selective leaking > by hand cfg. It goes without saying that subscription to selective leaking > MUST be automated. > > [WAJ] If not via configuration, how to accomplish the selective reaction? > By subscription. Just like any producer can register with local RIB to track some route it can also register with ABRs or RRs. [WAJ] No. After the PUA advertise period, only the normal summary address > will be remained. We focus only the “Down” moment, not “Down” state. > That means that any of my encapsulations will start dropping again in 60 sec (timer from PULSE draft). Oh that's pretty cool ! Note that again I am using your and Peter's case where there is no service BGP on top to remove service routes. Easy to say ... Sure you can remove the adj from FIB. But for how long - > that is the question - very important when we are talking about any > ephemeral form of signalling. > > [WAJ] If there is no other mechanism/protocol to bring up it, it will > remain down. > Only for the case of actual p2p tunnel establishment like IPSec or L2TPv3. In all other cases after PUA timer for all purposes of forwarding the sending router will start to send again using summary. That is a severe architecture/design issue IMO. What "other" mechanism are you talking about ? Thx, R.
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
