On Thu, Dec 2, 2021 at 2:03 PM Peter Psenak <[email protected]> wrote:
> Tony, > > On 02/12/2021 11:49, Tony Przygienda wrote: > > Idly thinking about the stuff more and more issues pop up that confirm > > my initial gut feeling that the pulse stuff is simply not what IGP can > > do reasonably (i.e. liveliness). negative as liveliness indication is > > arguably even worse ;-) but I think most of us agreed on that across > > those hundreds of emails by now. > > > > So, to expound a bit. IGP reachability which IGP does normally is _very_ > > different from liveliness and here's another example (I describe it in > > principle but people who deployed stuff will know what scenarios I'm > > talking about) > > > > So, in short, the fact that an IGP, let's say ABR, advertises a summary > > has _nothing_ to do much with liveliness of what it summarizes in system > > wide sense. In more specifics, even when this aggregate goes away or IGP > > cannot compute _reachability_ to a specific address/node does NOT mean > > that the prefix advertised by such node is not _alive_. > > > > Imagine (often done in fact in deployments I dealt with) that the prefix > > advertised by a node into IGP is not _reachable_ by IGP all of a sudden, > > simplest case being a link loss of course. However, it is in the system > > still reachable by means e.g. of a default route from another protocol > > or a specific route (static?) over a link IGP is not running on. Now, if > > IGP starts to pulse it will defeat the very purpose of such backup. > > no less specific route will ever make something that went down > reachable. we disagree based on my experience whereas the "went down" is only "IGP does not see it anymore" in the draft definition here unless we want to start to write in LSR draft that encompass multi-protocol router requirements and system design. > The purpose of the pulse is not to defeat the purpose of the > default, or less specific route. The purpose of the pulse is to notify > interested clients that the reachability of some less specific route > (typically a host route) that is covered by the summary in its source > area is lost. > > If a unique host route that was reachable in its source area became > unreachable because its originator became unreachable, we know for sure > that the host route is gone no matter what less specific routes may > cover it. > so if we intend to inform the service source that "IGP thinks it cannot reach an address anymore through an ABR (because other ABRs may still reach it [solving that preconditions AFAIS re-invention of add-path in IGP on leaking and/or lots interesting paxos-direction protocol work] but maybe other protocols/aggregates can still reach it)" so the source as you say "may do something" then it slowly deems to me that we are not standardizing anything but some "rough hunch of a rumour" I would never advise a customer to act upon given how very expensive a false positive on service is including e.g. BGP re-sync or tunnel tear-downs. > > > > > > And no, you cannot "know" whether backup is here, there are even funky > > cases where a policy only installs a backup route if the primary went > > away which may be fast enough to keep e.g. TCP up (whether it's the best > > possible architecture is disputable but it's a fact of live that such > > stuff exists). > > > > So, basically we try to invent "liveliness indication" in IGP whereas > > IGP cannot be aware whether the prefix is reachable system-wide through > > it even when IGP lost _reachability_. > > we can limit the pulse notification to host prefixes. That should > address your concern. > I would prefer not to add hidden /32 semantics to protocol features since the more things become "special" and "asymmetric" the harder it's to explain how things work & why they don't work when deployed as expected. -- tony
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
