On Wed, Nov 09, 2022 at 01:27:41PM +0000, Acee Lindem (acee) wrote: > I guess I'd like to understand what one would accomplish with further > specification of prefix reachable? What requirement would this > satisfy? For the use case UPA is designed to handle (triggering BGP > PIC or other local action) , I can't see that there would be any case > where you wouldn’t want to take this action for an unreachable prefix.
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. I vaguely remember several years back we did indeed implement something (seriously no memory on details) that resulted in the creation of a new prefix reachability TLV with some experimental/local sub-TLVs. These prefixes did not exist in the IS-IS domain beforehand. I have no idea what the operational reality is on the existence of such things, but I know that /some/ code exists that does this. To boil this down into the core of the essence and be explicit, - 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 - this has in fact been done to carry custom bits of information that for one reason or another were decided to be routing-related and thus make sense to put there - the assumption for the use case is that there are indeed less specific covering prefixes around, providing actual reachability - 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) - (if those extra prefixes are created with 0xffffffff metric, a configurable >= limit for UPA does not help either.) 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.) Cheers, -David _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
