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.” Then, let’s stick on the original statements about the meaning of “LSInfinity”, no more explanations, no more confusion then. Aijun Wang China Telecom > On Nov 9, 2022, at 12:06, Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org> > 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 > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
