Tony –
I have been trying to gain a better understanding of your thinking – thanx for
your responses which have helped in that regard.
I am not trying to convince you of anything – just want to add a few comments:
It is not clear to me why having the IGP advertise information that it already
knows is considered an “architectural violation”. It is even less clear to me
since it would not be considered a violation if an operator didn’t configure a
summary and the IGP advertised all the individual prefixes it knew about all
the time. (Whether that is a wise choice in a given deployment is another
matter.)
As to scale, you are making the assumption that a solution cannot be provided
without introducing significant scale issues – but I don’t think that is the
case.
I don’t want to use this thread to advocate for one candidate solution over
another – I think that is best addressed in some subsequent thread. Just want
to point out that the solution does not have to have the same scale
characteristics as having no summaries.
Thanx for the discussion.
Les
From: Tony Li <tony1ath...@gmail.com> On Behalf Of Tony Li
Sent: Sunday, November 21, 2021 10:56 PM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>
Cc: Aijun Wang <wangai...@tsinghua.org.cn>; Gyan Mishra
<hayabusa...@gmail.com>; Christian Hopps <cho...@chopps.org>; lsr
<lsr@ietf.org>; Acee Lindem (acee) <a...@cisco.com>; Tony Przygienda
<tonysi...@gmail.com>
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR
Meeting Minutes
Les,
The problem is that restricting the prefix length does nothing to limit the
number of advertisements that get flooded. In a high-scale situation, when
there is a mass failure, it would lead to a flooding spike. That’s exactly not
the time to stress the system.
[LES:] As I have stated previously, I share your concern about the behavior
during massive events – and some care has to be taken to prevent making a bad
situation worse.
That said, the WG (including you and I) is taking on enhancements to support
much faster flooding – on the order of hundreds (perhaps thousands) of
LSPs/second. We believe this can be done safely (though proof has not yet been
established).
And the point of doing that was to help improve IGP convergence time…
So, if you believe (as your active participation suggests) that IGPs can
support faster flooding – why do you believe they cannot support liveness
notification at a similar scale?
… not waste our time by inflating the LSDB by the same amount that we sped up
flooding.
Also, I don’t see how faster flooding has ANYTHING to do with it. Adding
negative liveness information is primary a scale issue.
I get that you consider such notifications as architecturally undesirable – we
can agree to disagree on that point.
But I don’t get why you think the IGP’s ability to handle large scale events is
a showstopper in this case.
I am opposed to anything that adds to the scale of the LSDB. Doubly so if it
does so during failures, when the IGP is already under stress. As you well
know, making an IGP stable during normal operations is one thing. Ensuring that
it is stable during worst case topological changes is quite another. Adding
scale during a mass failure is pessimal timing.
T
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
