On 18/11/2021 15:54, Robert Raszuk wrote:
Btw even with eBGP between TOR and compute I have just checked and I see
cases of some deployments not setting next hop self on TORs hence
original next hop set by compute is used in service routes.
Link between TOR and compute is passive IGP link/subnet.
that's what I thought would be the case. And in such case the IGP
solution would work for you.
Peter
Thx,
R.
On Thu, Nov 18, 2021 at 3:17 PM Aijun Wang <[email protected]
<mailto:[email protected]>> wrote:
Hi, Robert:
If you use iBGP in your mentioned scenario, how to propagate the
reachability of BGP nexthop? I think it is impossible to use again
BGP itself. Then depend only BGP can’t solve your problem.
If the underlying using IGP to propagate such reachability
information, we have mechanism to control for which covered prefix
to send the notification when they become unreachable. It is not
randomly suppressed.
Aijun Wang
China Telecom
On Nov 18, 2021, at 21:27, Robert Raszuk <[email protected]
<mailto:[email protected]>> wrote:
In such cases I would rather consider implementing pulse to be
less then host route.
Suppressing them randomly may lead to even bigger disappointment
of unreachability propagation hence delaying connectivity
restoration to a backup path.
Many thx,
R.
On Thu, Nov 18, 2021 at 1:58 PM Peter Psenak <[email protected]
<mailto:[email protected]>> wrote:
Robert,
On 18/11/2021 13:42, Robert Raszuk wrote:
> [WAJ] In the scenarios that you mentioned, BGP nexthop
reachability
> is derived from the directed interface, there is no
summary action
> done by the router. Is that true?
>
>
> Not necessarily - TORs do not always do eBGP to compute and
set next hop
> self. There can be IBGP session there and therefor next hop
is not
> changed all the way to the remote compute. But the point was
that today
> BGP is involved already in reachability and service
distribution.
>
> And while current IGP proposals can propagate this too the
point is
> about scalability when it comes to signalling of such
massive failures
> in the IGP. The amount of IGP traffic and processing in
those moments
> may be significant.
we can certainly address such case by not allowing thousands
of pulses
to be generated in case half of the universe falls apart. That
seems
obvious and easy to implement.
thanks,
Peter
>
> And yes I agree this is not really a "hole punching" ...
that was just a
> description shortcut I used.
>
> Thx,
> R.
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
