Hi Chris, > If that means they are installing a negative route then they are modifying the IP routing table. > If he meant they don't do anything with the announcement, well then that's in spec.
There are lots of options between installing negative route in IP routing table and not doing anything with that. As example negative route may be passed directly to BGP to invalidate BGP next hop and trigger a new best path run on a set of routes which happen to select path with such next hop as best. That would not require to install negative route anywhere. Second an implementation may have N RIBs - one of them be negative and be used for next hop validation. It is clearly not an IP routing table in terms of IP reachability. A good test perhaps would be to locally originate ICMP ping to PUA covered dst from PUA receiving node after getting PUA for 1.1.1.1/32 (before the timeout) ... If ICMP packets will go out of the box to IGP neighbor as covered by say summary of 1.1.1.0/24 that means PUA is in spec as IP routing table is unaltered. If we would not see such packets that would mean there is base for more discussions and the point you are making stands. Cheers, Robert On Sun, Nov 13, 2022 at 1:18 PM Christian Hopps <cho...@chopps.org> wrote: > > Robert Raszuk <rob...@raszuk.net> writes: > > > Chris, > > > >> unreachable routes in the IP routing table > > That quote leaves zero context at all for what I was saying. > > I was replying to Peter saying that implementations are using the max > metric announcements to avoid sending traffic to overload routers. If that > means they are installing a negative route then they are modifying the IP > routing table. If he meant they don't do anything with the announcement, > well then that's in spec. > > Thanks, > Chris. > > > > > I don't see anywhere in the UPA spec even a hint that those > > unreachable pulses would be installed in the IP routing table. It > > seems to be a local implementation choice how ISIS or OSPF would > > inform other protocols about them. > > > > In fact the quote you provided specifically "other than building the > > normal IP routing table" IMO endorses quite verbatim what Peter > > claims. They can be used for other purposes then building a > > reachability table. > > > > Thx, > > R. > > > > > > > > > > > > > > On Sat, Nov 12, 2022 at 6:47 AM Christian Hopps <cho...@chopps.org> > > wrote: > > > > > > > > > On Nov 9, 2022, at 2:13 PM, Peter Psenak <ppsenak= > > 40cisco....@dmarc.ietf.org> wrote: > > > > > > On 09/11/2022 14:56, David Lamparter wrote: > > >> 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. > > > > > > 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. > > > > [as wg-member] > > > > But his interpretation seems correct. RFC5305 says specifically > > that the prefix is not to be used for building the normal IP > > routing table, that would include not creating/installing > > blackhole/reject routes in the normal IP routing table. > > > > If a prefix is advertised with a metric larger then > > MAX_PATH_METRIC > > (0xFE000000, see paragraph 3.0), this prefix MUST NOT be > > considered > > during the normal SPF computation. This allows advertisement > > of a > > prefix for purposes other than building the normal IP routing > > table. > > > > Do the implementations you’re referring to install unreachable > > routes in the IP routing table, seemingly in violation of this? > > > > Thanks, > > Chris. > > > > > > >> 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) > > > > > > and why that would be a problem? Such prefix would never be > > used to for resolution of the BGP prefix. So the presence of such > > unreachable prefix would never trigger any action even of the UPA > > processing was enabled on the receiver. I don't see a problem. > > > > > >> - (if those extra prefixes are created with 0xffffffff metric, > > a > > >> configurable >= limit for UPA does not help either.) > > > > > > again, what is the problem? > > > > > >> 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. > > > > > > thanks, > > > Peter > > > > > >> Cheers, > > >> -David > > > > > > _______________________________________________ > > > Lsr mailing list > > > Lsr@ietf.org > > > https://www.ietf.org/mailman/listinfo/lsr > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > > > > > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
