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. 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. > > 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? Thanks, -David _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
