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

Reply via email to