Peter, > From: Peter Psenak <ppse...@cisco.com> > Sent: Thursday, July 27, 2023 8:00 PM > > Bruno, > > On 27/07/2023 16:12, bruno.decra...@orange.com 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
