Bruno,
On 10/11/2022 02:18, [email protected] wrote:
Peter,
From: Peter Psenak <[email protected]>
Sent: Wednesday, November 9, 2022 2:13 PM
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.
I'm a bit surprised since even draft-ppsenak-lsr-igp-ureach-prefix-announce
seems to say the contrary:
Old nodes:
" Existing nodes in a network which receive UPA advertisements will
ignore them."
New nodes:
"As per the definitions referenced in the preceding section, any
prefix advertisement with a metric value greater than 0xFE000000 can
be used for purposes other than normal routing calculations. Such an
advertisement can be interpreted by the receiver as a UPA."
https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-ureach-prefix-announce-01#section-2.1
So draft seems to clearly state that the UPA is a new interpretation leading to
a new behavior.
To me, the difference of opinions expressed on the list is the following:
a) draft-ppsenak-lsr-igp-ureach-prefix-announce is fine with the specific
metric value being locally interpreted as UPA even though that's not a
standard/global behavior
b) multiple other persons on the list have preference for an explicit signaling with a
standardized meaning being "UPA"
I agree that "a" can be made to work, with a local interpretation through local
config or new code.
thanks for admitting that.
But:
- that is nonetheless a change which is non backward compatible with people
currently using such high metric without the intention to mean UPA
- to differentiate different usages (e.g. your UPA, my other usage such as "graceful shutdown" (still reachable but will disappear soon), endpoint CPU load is 80%...) one
well, the question is whether it would not make sense to trigger UPA for
the above mentioned usages as well. Because eventually the destination
is becoming unreachable anyway and I would want my services to reroute
to alternate egress node. But seems like folks want to have a way to
differentiate, so I'm not going to argue against it.
thanks,
Peter
would need to use different metric values that would need to be at least
locally registered. So why not have the IANA register a flag and avoid each
network operator to do that job?
In all cases, I don't see a reason for UPA to change the meaning of all the metric
values >0xFE000000. You can pick a single value (e.g. 0xFE000001) and that
would equally work for your use case.
Regards,
--Bruno
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
Orange Restricted
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
