The way I read this is that other applications could use the generic IGP pulse mechanism as opposed to other applications using the route unreachable signals conveyed using the IGP pulse mechanism. Thanks, Acee
From: Lsr <lsr-boun...@ietf.org> on behalf of Robert Raszuk <rob...@raszuk.net> Date: Thursday, January 6, 2022 at 6:54 AM To: "Peter Psenak (ppsenak)" <ppse...@cisco.com> Cc: Hannes Gredler <han...@gredler.at>, Bruno Decraene <bruno.decra...@orange.com>, Tony Li <tony...@tony.li>, Shraddha Hegde <shrad...@juniper.net>, lsr <lsr@ietf.org> Subject: Re: [Lsr] BGP vs PUA/PULSE 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 <rob...@raszuk.net<mailto:rob...@raszuk.net>> 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 <ppse...@cisco.com<mailto:ppse...@cisco.com>> 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
