Hi, Robert: Aijun Wang China Telecom
> On Nov 27, 2021, at 18:17, Robert Raszuk <[email protected]> wrote: > > > 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. [WAJ] If such thing happen, won’t the BGP update will also be affected? The underlying IGP are converging. > >> [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. [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? > > >> [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. [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 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] 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. > >> [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. [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. > >>> 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. [WAJ] Using the backup tunnel until the primary node is brought up again. > > What "other" mechanism are you talking about ? [WAJ] Like what you mGRE at https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_l3_vpns/configuration/15-s/mp-l3-vpns-15-s-book/ir-l3vpn-mgre.html#GUID-066024B8-051D-4891-931E-F8B463C008BA > > Thx, > R. > > > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
