On Wed, Nov 09, 2022 at 03:16:11PM +0000, Peter Psenak wrote: > On 09/11/2022 15:48, David Lamparter wrote: > > On Wed, Nov 09, 2022 at 02:32:35PM +0000, Peter Psenak wrote: > >> as far as that /128 is not used as BGP next-hop (which obviously is not > >> the case), > > > > You keep saying things are "obvious"; they are not. Why are you > > assuming that my /128 is not in fact used as a BGP next-hop? > > > > My /128 is a routing no-op right now. The /64 is what gives the nexthop > > reachability. With your change, the /128 takes precedence as a more > > specific unreachable. > > well, if you have a service end-point that is advertised as /128 with > unreachable metric
metric > 0xfe000000 is not "unreachable". It's "no information". You have to continue in your SPF and use less specific prefixes if any are available. That's the entire point of this thread and/or the different reading we have of 5305/5308. > and you expect your services to work, I would be very careful. We can > speculate whether that is something that is suppose to work or not, As noted in an earlier mail, I'm not speaking speculatively. Code exists that does this. The services work. I have no information on how common the pattern is, but I can positively affirm its existence. [...] > >> If you introduce a new mechanism, routers not understanding the new > >> extension would still consider the prefix reachable. > > > > ... and routers not understanding the new extension will continue > > blissfully ignoring the prefix, as they did before. Why do you think > > the prefix is suddenly considered reachable? The prefix would still > > have > 0xfe000000 metric, is that the point of misunderstanding in this > > thread? > > you did not say that before, did you? Bruno did, it's in a direct ancestor to this mail (parent to Acee's mail); I assumed you had read it: (I:) > > > I'd rather not do that and just add a sub-TLV for it. (Bruno:) > > I'm fine to use max_prefix as per RFC 5305 (prefix not considered during > > SPF) as this allow for incremental deployment. > > But in my opinion, advertising the unreachability semantic requires an > > additional explicit signaling. (I'm proposing a prefix flag, but that seem > > like a detail at this point) (I:) > ACK [...] > > I wasn't clear on that in the first mail but Bruno clarified > > that this would still be inside a high-metric prefix reachability TLV. > > The only difference is that there is a flag/sub-TLV inside that triggers > > UPA behavior. However, prefixes with > 0xfe000000 metric *without* > > the UPA indicator MUST be ignored as they were before and MUST NOT > > trigger UPA/PIC. > > for me flagging something that is unreachable with a unreachable flag is > redundant. But I let the WG to decide. That would obviously push the > draft to standard track trajectory. It would already need to be on standards track as it is, since it is changing IS-IS behavior in an incompatible way. Or, again, we need to errata 5305/5308. The wording seems pretty clear to me, but apparently the way I consider it to be clear in differs from the way you consider it to be clear in. That's the worst kind of ambiguity, when the ambiguity itself is insidiously hidden... Sighing, -David _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
