On 10/11/2022 11:59, Acee Lindem (acee) wrote:
Hi Robert,
*From: *Robert Raszuk <rob...@raszuk.net>
*Date: *Thursday, November 10, 2022 at 10:51 AM
*To: *Acee Lindem <a...@cisco.com>
*Cc: *Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org>, Bruno Decraene
<bruno.decra...@orange.com>, David Lamparter <equi...@diac24.net>,
"lsr@ietf.org" <lsr@ietf.org>
*Subject: *Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA
IS-IS semantics
> But BGP service PIC is the use case this draft is targeting?
For many emails on LSR and beyond I got point from authors against using
BGP for such signalling as "BGP may not be running there at all".
So if the draft works *only* with service provided by BGP let's please
state it clearly in the document. This is not my current assumption.
I think the point of this was that it could be other applications where
an ephemeral unreachability notification is useful. For this type of
notification, recursive route resolution is the primary application.
However, I’ll defer to the authors.
that is correct indeed.
thanks,
Peter
Thanks,
Acee
Many thx,
R.
On Thu, Nov 10, 2022 at 11:47 AM Acee Lindem (acee) <a...@cisco.com
<mailto:a...@cisco.com>> wrote:
Hi Robert,
*From: *Robert Raszuk <rob...@raszuk.net <mailto:rob...@raszuk.net>>
*Date: *Thursday, November 10, 2022 at 9:41 AM
*To: *Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org
<mailto:40cisco....@dmarc.ietf.org>>
*Cc: *Bruno Decraene <bruno.decra...@orange.com
<mailto:bruno.decra...@orange.com>>, David Lamparter
<equi...@diac24.net <mailto:equi...@diac24.net>>, Acee Lindem
<a...@cisco.com <mailto:a...@cisco.com>>, "lsr@ietf.org
<mailto:lsr@ietf.org>" <lsr@ietf.org <mailto:lsr@ietf.org>>
*Subject: *Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce /
UPA IS-IS semantics
Peter,
> 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.
I think You are right if there is a hierarchical service above it.
But consider flat routing - where there is no BGP service on top.
Example - some DCs do use flat routing.
With that I am afraid UPA triggers may not work well (or at all) ...
especially considering that they are history after the timeout
irrespective of the remote prefix state.
But BGP service PIC is the use case this draft is targeting? For
example, there is no intent to install negative routes throughout
the domain.
Thanks,
Acee
Cheers,
R.
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
Lsr@ietf.org <mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
<https://www.ietf.org/mailman/listinfo/lsr>
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
