On 09/11/2022 16:32, David Lamparter wrote:
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.
if the "no information" results in unreachability, which is clear from
the 5305/5308, we can use it to signal unreachability.
Anyway, we can keep arguing, but will hardly reach an agreement. The
decision is on the WG.
What is important is that we will use the metric > 0xfe000000 for
signalling unreachability whether we add something on top of it or not.
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.
well, I doubt such code has ever been deployed in production. And I can
tell you it will likely break many implementations :)
Peter
[...]
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
