Robert,
On 06/01/2022 12:31, Robert Raszuk 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*.
not necessarily. Pulse can be treated similarly as the BGP NH down and
it would still result it PIC like behavior.
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 :).
pretty much, but it's not a rocket science and people will figure it out.
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.
you see, you are already finding out the PIC way :)
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.
again, it's an implementation choice, there are multiple ways to do it.
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.
several ways to implement that local behavior.
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 !
it does not change any of the above though :)
thanks,
Peter
On Thu, Jan 6, 2022 at 10:25 AM Peter Psenak <[email protected]
<mailto:[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
