Aijun,
On 09/11/2022 13:21, Aijun Wang wrote:
Hi, Peter:
I think you over explain the meaning of “LSInfinity”. I concur with David:
A less specific prefix may cover it
Then, you conclusion that:
when a prefix is "not considered during the normal Shortest Path First (SPF)
computation", the result will be that the prefix will become unreachable. I guess we
can agree on that
Is NOT correct.
“the result will be that the specific prefix isn’t existing within the FIB, but
not unreachable——-because there may be one less specific prefix covers it.”
and what exactly is the point? You can have a default route in your
domain. Are you saying that in such case every destination is reachable?
Obviously not.
Then, let’s stick on the original statements about the meaning of “LSInfinity”,
no more explanations, no more confusion then.
we are not changing that in any way.
Peter
Aijun Wang
China Telecom
On Nov 9, 2022, at 12:06, Peter Psenak <[email protected]>
wrote:
Hi David,
On 09/11/2022 11:44, David Lamparter wrote:
Hi Peter, hi all,
to iterate on the comment I made on the mic a few minutes ago, I
apparently have a rather different understanding of existing IS-IS
behaviour. Reading 5305/5308,
... "if a prefix is advertised with a metric larger
than MAX_V6_PATH_METRIC (0xFE000000), this prefix MUST not be
considered during the normal Shortest Path First (SPF)
computation."
A prefix that is "not considered" is not an unreachable prefix. It's a
prefix that is in the DB but ignored entirely, as if it wasn't there at
all. A less specific prefix may cover it, and I would expect that to
work normally.
when a prefix is "not considered during the normal Shortest Path First (SPF)
computation", the result will be that the prefix will become unreachable. I guess we
can agree on that.
And I'm not sure what do you mean by "in the DB but ignored entirely". It will
not be ignored, it will be maintained similarly in the DB as any other reachable prefix.
The UPA draft is changing this such that now some values may mean that
the prefix is in fact unreachable. I'd rather not do that and just add
a sub-TLV for it.
We are not changing anything in terms of meaning of the prefix metric higher
than 0xFE000000 - and that is why this is backward compatible. If we would be
changing the meaning of the metric it would not be.
Using a new Sub-TLV to signal unreachability makes the solution non backward
compatible, and harder to deploy, for no good reason IMHO.
thanks,
Peter
(Alternatively, if I misunderstood 5305/5308 - I'm pretty sure I'm not
the only one to read it that way and that's a pretty important
errata?!?)
Cheers,
-David
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
