On 09/11/2022 15:26, David Lamparter wrote:
On Wed, Nov 09, 2022 at 02:13:17PM +0000, Peter Psenak wrote:
On 09/11/2022 14:56, David Lamparter wrote:
On Wed, Nov 09, 2022 at 01:27:41PM +0000, Acee Lindem (acee) wrote:
The problem is that a prefix with metric > 0xfe000000 isn't actually an
unreachable prefix, it's a prefix that doesn't have specific routing
information associated with it, which in turn allows sticking other data
into it that might be routing-related but not quite a reachability.
well, that is your interpretation. For me a prefix with metric >
0xfe000000 is unreachable. Implementations use the max-metric today to
signal the prefix unreachability - to avoid reaching
local/leaked/redistributed prefixes in cases where OL-bit is set on the
originator. So we are not doing anything new here really.
That is my interpretation and our implementation. If we are discovering
ambiguity in this, we seriously need to errata-fix it, as noted in my
original mail. (And I'll happily fix our implementation too.)
- you can create an IS-IS prefix reachability for some arbitrary prefix,
and stick > 0xfe000000 into the metric, and that won't have any effect
on the existing IS-IS domain
[...]
- any setup doing that would now suddenly have fresh "unreachable"
semantics attached to something that didn't have them before, which
breaks things (or rather: prevents enabling/deployment of the UPA
feature)
and why that would be a problem? Such prefix would never be used to for
resolution of the BGP prefix.
Says who? If I have an external BGP nexthop on a shared network (e.g.
IXP), my IS-IS may have a route for the IXP's IPv6 /64, and I may have
an additional /128 in IS-IS with 0xffffffff metric in IS-IS carrying
ancillary data.
as far as that /128 is not used as BGP next-hop (which obviously is not
the case), UPA for such /128 is harmless.
The 5305/5308 text is - for me, quite clearly - saying this 0xffffffff
prefix I just arbitrarily stuck in there has no effect on routing
operation at all. Now it suddenly does.
what is the difference you see? I see none.
Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is
(IMHO) not a significant cost, and completely eliminates this issue.
The only reason against it (that I can think of) is that the
advertisement might be a little bit larger; a new sub-TLV or flag bit
should be completely invisible to existing implementations (= I don't
see how this would create compatibility or rollout problems.)
I'm afraid, you forgot to consider an operational aspect of the solution.
Please elaborate what that operational aspect is?
metric > 0xfe000000 will not result in prefix reachability on any
existing router. If you introduce a new mechanism, routers not
understanding the new extension would still consider the prefix reachable.
thanks,
Peter
Thanks,
-David
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
