On 12/11/2022 06:45, Christian Hopps 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?
no.
And we are not proposing anything like that to be done with UPA either.
The usage of the UPA is up to the receiving application. How it deals
with the UPA signal is outside of the scope of the UPA draft.
thanks,
Peter
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
