Robert,
On 29/11/2021 23:53, Robert Raszuk wrote:
Hi Les,
Just to summarize my personal take on this thread in the light of your
last email.
#1 - I am not ok with the ephemeral nature of the advertisements. (I
proposed an alternative).
LSPs have their age today. One can generate LSP with the lifetime of 1
min. Protocol already allows that. So you are "not ok" with what
protocol allows already. I'm fine if that's your position, but making
that an argument against the proposal is not correct IMHO.
#2 - I am not ok with spreading the information everywhere including all
P and PE routers which do not need it.
Today in all MPLS networks host routes from all areas are "spread"
everywhere including all P and PE routers, that's how LS protocols
distribute data, we have no other way to do that in LS IGPs.
Summarization with what we propose reduces the "spread" significantly.
And we cam easily address the "mass failures", so we will never generate
as many pulses as we have host routes today. If you still don't like it,
fine, but arguing that the existing distribution method in IGP is
incorrect is not a valid argument IMHO.
#3 - 1 days ago you said: "The legitimate question is whether folks see
it as appropriate to have an IGP based solution for the problem." So
bringing a BGP alternative seems to be very much in line with your
guidance for this thread. >
#4 - I am not sure it is OK for IGP to advertise a bunch of area local
info to every IGP node. The fact that it was pushed through IETF with
brute force does not make it a great protocol evolution. Maybe now it is
time to close that gate ?
same as (2).
thanks,
Peter
Kind regards,
Robert
[LES:] BGP-LS only advertises what the IGPs themselves advertise. ____
In this case, both IGP proposals involve ephemeral advertisements -
so even if we were to define BGP-LS support for these new
advertisements - they wouldn't persist long enough to be reflected
in BGP-LS.____
So, I really don’t know why we are discussing BGP-LS in the context
of this thread.____
(This seems to be one example of what Acee correctly identified as
this discussion going "off track".)____
[LES:] I am not convinced either side can claim "consensus" in this
discussion. That is a work in progress. 😊____
However, when you say IGPs are (exclusively?) for topology discovery
- it seems to suggest that IGP shouldn’t be advertising prefix
reachability at all. Hopefully, that is not what you intend.____
__ __
One of the points that still baffles me is the assertion of an
architectural violation in the IGP proposals.____
__ __
It is OK for IGPs to advertise all prefixes covered by a summary
(i.e., do not summarize).____
It is OK for IGPs to advertise multiple summaries (e.g., multiple
/24s instead of a single /16).____
It is even OK for IGPs to advertise some prefixes covered by a
summary along with the summary (don’t know if any implementations do
this - but they could).____
None of this is an "architectural violation".____
__ __
But advertising a summary and signaling the loss of reachability to
a specific prefix covered by the summary is seen by some as an
architectural violation.____
Sorry, I still don't understand this argument.____
__ __
You can not like the approach. You can be concerned about scaling
properties (more on that below). You can question the effectiveness
of ephemeral advertisements.____
These kinds of objections/concerns I can easily understand - even if
we don’t agree on their significance.____
But claiming that "IGPs are not supposed to do this"??____
Not grokking this.____
__ __
We have not added any new information to the IGP itself. We are only
suggesting a new form of advertisement to signal some information
already known to the IGP, but which is currently not advertised (in
some deployments) by the configuration of summaries.____
[LES:] The questions of scale (as I have previously commented) are
very legitimate - and more has to be specified before an IGP
solution would be considered ready for deployment. But there are
tools easily applicable to address this (rate limiting, embedded
summarization, perhaps others).
The more significant point is to focus on the goal - which in this
usage is improved convergence time.____
When the network is largely stable, convergence improvements can be
achieved w/o risk.____
When widespread failures occur, real time signaling of any type is
unlikely to provide improved convergence - which is why the IGPs
today shift the focus from convergence to stability by slowing down
the rate of updates sent and SPFs performed. This is STILL true even
in the fast convergence/FRR era.____
I see no reason why the same tools should not be used in this case.____
__ __
Les
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
