Apologies ... want to correct myself for clarity: was: "active and backup paths all going to the next hop X"
should be: "active paths all going to the next hop X and backup paths going to different next hops" On Thu, Jan 6, 2022 at 12:31 PM Robert Raszuk <[email protected]> wrote: > Peter, > > So far you and others have been saying all along that one of the > applications which uses PULSE can be BGP. > > If so I am afraid this is not PIC (== Prefix *Independent *Convergence) > anymore. And I think this was Bruno's valid point. > > Today BGP registers with RIB next hops for tracking, When next hop goes > down or metric changes BGP get's notification. So now there needs to be a > new construct stating that registered next hop went away based on PULSE > signaling and *all* best paths need to be recomputed (or in case of > multipath enabled - removed). So yes this is a trigger, but it is *PER > PREFIX*. > > That is my current understanding of how PULSE will be used. All of this is > a guess as you keep this part as an implementation detail/secret :). That > is also compatible with the notion of recomputation of the removed best > path when PULSE expires. > > Now one could potentially do it in a different way - PIC style - that is > first to preinstall in FIB active and backup paths all going to the next > hop X and simply invalidate this next hop X when PULSE arrives with single > adj rewrite - directly in the FIB itself. > > But in this case PULSE will never be heard by BGP or for that matter by > any other app - not giving them a chance to select another best path in > case of no iBGP multipath to be enabled. You could also propagate this to > both BGP and FIB. > > What seems big unknown in the latter case is the operation aspect of those > events in the light of the ephemeral nature of PULSE. I am sure you are > going in either case to generate a syslog message upon PULSE reception. > Extending current RIB, building shadow ephemeral RIB or bypassing it to > talk directly between IGP and FIB is another operational concern. > > Thx, > Robert. > > PS. Also keep in mind that in SRv6 used say for VPN applications you do > not want to signal /128 next hops but SID locator prefix of the remote > egress PE :) This is going to be fun ! > > > > On Thu, Jan 6, 2022 at 10:25 AM Peter Psenak <[email protected]> wrote: > >> Bruno, >> >> the PIC is used unchanged with PULSE. >> >> The only difference is that the PIC is triggered by the pulse arrival, >> instead of the IGP route removal. We have made a prototype of it and it >> works fine. >> >> thanks, >> Peter >> > >>
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
