Hi Bruno,
I will update the draft.
thanks,
Peter
On 28/07/2023 14:32, [email protected] wrote:
Peter,
From: Peter Psenak <[email protected]>
Sent: Thursday, July 27, 2023 8:00 PM
Bruno,
On 27/07/2023 16:12, [email protected] wrote:
Bottom line:
- we see that this can be problematic in some cases
- it's very easy to fix by mandating the use of the flags(s).
I believe we understand each other. I even believe we are in a violent
agreement, although we have different view on some specific details.
Would SHOULD language in terms of using the new flags for UPA take care
of your concerns?
To summarize, my concern is that with the current text, any advertisement with
a metric higher than 0xFE000000 would be interpreted as UPA by nodes enabling
UPA. This essentially forbid any past or future use of this whole range of
metric, which I find problematic and unnecessary.
There may be multiple ways to address this. I can think of two (below) but I'm
open to other solutions that you would propose.
1) UPA behavior is triggered by one a the flag being set (and metric
>0xFE000000)
2) UPA is triggered by a specific metric value. This would allow other usages
to pick a different value without interfering with UPA. If so I would have a
preference to have a registered value so creating an IANA registry would be
needed (with some values for private use)
...
(Clearly, we only need one, not both of them).
Coming back to your proposal (thank you) and your question, if option 1 (flag)
is used, my proposed changes are detailed in
https://mailarchive.ietf.org/arch/msg/lsr/AN6Lfd58i5RS3cq06EqwOyrOLGY/
They are recopied below for ease of discussion (and to fix some errors)
§5.4
OLD: U-Flag and UP-Flag are optional flags that have informative character.
Treatment of these flags on the receiver is optional and the usage of them is
outside of scope of this document.
NEW: The setting of the U-Flag or the UP-Flag signals that the prefix is
unreachable. They constitute the UPA signals.
§5
"Even though in all cases the treatment of such metric, or NU-bit, is specified for
IS-IS, OSPF and OSPFv3, having an explicit way to signal that the prefix was advertised
in order to signal unreachability is useful to distinguish it from other cases where the
prefix with such metric is advertised."
:s/useful/required
§Abstract
OLD: This document describes how to use existing protocol mechanisms in IS-IS
and OSPF to advertise such prefix reachability loss.
NEW: This document defines two new flags in IS-IS and OSPF to advertise such
prefix reachability loss. In order to support incremental deployment, such
advertisement use a high metric value already having special meaning in OSPF
and IS-IS.
§1
OLD: This document describes how the use of existing protocol mechanisms can
support the necessary functionality without the need for any protocol
extensions. The functionality being described is called Unreachable Prefix
Announcement (UPA).
NEW: This document defines two new flags in IS-IS and OSPF to support the
necessary functionality. The functionality being described is called
Unreachable Prefix Announcement (UPA).
I would propose an additional editorial change
OLD: 5. Signaling the UPA origin
NEW: 5. Signaling UPA
OLD: 5.1. Signaling the UPA origin in IS-IS
NEW: 5.1. Signaling UPA in IS-IS
Please feel free to reformulate as needed.
I've focused on IS-IS. I leave the OSPF parts up to you.
Thanks,
--Bruno
What's preventing the authors to just fix this?
In the absence of an implementation section in the draft, does the only
disclosed implementation (IOS-XR) support the flags and set a flag with the UPA?
I don't think discussing the details of the particular implementation
belongs to this list. We can discuss that privately.
thanks,
Peter
Thanks,
--Bruno
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
