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