Robert –

For me dealing with “mass failure” is important – but is easily doable.
It is basic to IGP flooding that we limit the rate at which new versions of 
LSPs are generated.
Analogous (but not identical) controls can be applied to pulse advertisements – 
and should be. We will address that in the next version of the draft.

The substantive debate in my mind is that some people think it appropriate for 
IGP to advertise loss of reachability to destinations covered by an IGP 
originated summary advertisement and some folks do not.

Thanx.

   Les

From: Robert Raszuk <rob...@raszuk.net>
Sent: Friday, November 19, 2021 12:25 PM
To: Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org>
Cc: Tony Li <tony...@tony.li>; Les Ginsberg (ginsberg) <ginsb...@cisco.com>; 
Gyan Mishra <hayabusa...@gmail.com>; Christian Hopps <cho...@chopps.org>; Aijun 
Wang <wangai...@tsinghua.org.cn>; 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

Peter,

yes, but it's not specific to flat areas. Even in multi-area deployments
the host routing is mandated by MPLS.

In the early days of MPLS yes that was the case.

But that "mandate" was fixed by Ina, Bruno and Jean-Louis in 2008 :)

https://datatracker.ietf.org/doc/html/rfc5283

In these multi-area deployments
the host routes are sent everywhere, updates are triggered regardless of
the failure type. IGPs are effectively providing liveness service
between PEs in any MPLS network.

That is true too - as folks just do not know how to configure BGP properly (if 
BGP is used for services).

That leaves us the space what to do where there is no BGP carrying services. Or 
BGP implementation is broken and can not do the right thing.

For the pulse proposal - no one answered the question posted what is a 
definition of mass failure. But maybe that will be the secret sauce of a vendor 
:) ?

The fact that we are all in agreement that some network events will not work 
that well with the proposed solution seems to be a sufficient reason for me to 
consider different solution(s).

Thx,
R.
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to