On 22/11/2021 08:45, Les Ginsberg (ginsberg) wrote:
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.)
it's not a choice, that is an MPLS architectural requirement and it
happens in every single SP network that offers services on top of MPLS.
If that is considered architecturally incorrect, then the whole MPLS
would be. But regardless of that, it has been used very successfully for
last 30 years.
thanks,
Peter
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
