On 09/11/2022 15:48, David Lamparter wrote:
On Wed, Nov 09, 2022 at 02:32:35PM +0000, Peter Psenak wrote:
On 09/11/2022 15:26, David Lamparter wrote:
On Wed, Nov 09, 2022 at 02:13:17PM +0000, Peter Psenak wrote:
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),
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 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, IMHO it is hardly something that we need to worry about.
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.
The difference is that I already have a /128 with 0xffffffff metric in
my IS-IS domain, which with your draft enabled is now processed to tell
BGP that the nexthop is unreachable. It didn't do that before.
the question is whether that matters or not, please see above.
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.
It results in nothing, yes ...
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?
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.
Peter
Cheers,
-David
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
