Hi, Robert: > "other than building the normal IP routing table"
There may be different purposes, so advertise the “unreachable within the summary address” should be signed explicitly. Aijun Wang China Telecom > On Nov 12, 2022, at 11:59, Robert Raszuk <[email protected]> wrote: > > > Chris, > > > unreachable routes in the IP routing table > > 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 <[email protected]> wrote: >> >> >> > On Nov 9, 2022, at 2:13 PM, Peter Psenak >> > <[email protected]> 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 >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/lsr >> >> _______________________________________________ >> Lsr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
