Peter, > From: Peter Psenak <[email protected]> > Sent: Wednesday, July 26, 2023 11:26 PM > > Bruno, > > please see inline (##PP): > > On 26/07/2023 22:46, [email protected] wrote: > > Peter, > > > > Please see inline > > > >> From: Peter Psenak <[email protected]> > >> > >> Bruno, > >> > >> please see inline: > >> > >> On 25/07/2023 21:11, [email protected] wrote: > >>> Peter, > >>> > >>> Please see inline > >>> > >>>> From: Peter Psenak <[email protected]> > >>>> Sent: Tuesday, July 25, 2023 6:49 PM > >>>> > >>>> Bruno, > >>>> > >>>> please see inline: > >>>> > >>>> On 25/07/2023 18:36, [email protected] wrote: > >>>>> Peter, > >>>>> > >>>>> Thanks for your answer. > >>>>> Please see inline [Bruno] > >>>>> > >>>>> > >>>>>> From: Peter Psenak <[email protected]> > >>>>>> Sent: Tuesday, July 25, 2023 6:05 PM > >>>>>> > >>>>>> Bruno, > >>>>>> > >>>>>> On 25/07/2023 14:39, [email protected] wrote: > >>>>>>> Hi all, > >>>>>>> > >>>>>>> With RC5305, in IS-IS we can advertise two states for a prefix IP1: > >>>>>>> > >>>>>>> * Positive reachability (state “1”), by advertising IP1 in TLV > >>>>>>> 135 > >>>>>>> with a metric lower than 0xFE000000 > >>>>>>> * No reachability (state “0”) by either: > >>>>>>> o Not advertising IP1 in TLV 135 > >>>>>>> o Advertising IP1 in TLV 135with a metric larger than > >>>>>>> 0xFE000000 > >>>>>> > >>>>>> right, one being implicit the other one explicit. > >>> > >>> > >>> Here you agree that advertising IP1 in TLV 135with a metric larger than > >>> 0xFE000000 is equivalent to No reachability / state “0” / Not advertising > >>> IP1 in TLV 135 > >>> > >>>>>> > >>>>>>> > >>>>>>> For unreachable prefix announcement, we need to advertise a new state: > >>>>>>> negative reachability (state “-1”) because advertising no reachability > >>>>>>> (state “0”) is not enough since there is a covering prefix advertised. > >>>>>>> > >>>>>>> Hence we need a new signaling. > >>>>>>> > >>>>>>> draft-ppsenak-lsr-igp-ureach-prefix-announce is proposing to advertise > >>>>>>> IP1 unreachability by advertising IP in TLV 135 with a metric larger > >>>>>>> than 0xFE000000. > >>>>>>> > >>>>>>> This does not work as this signal is already defined to advertise > >>>>>>> state > >>>>>>> “0” (no reachability) while we want to advertise negative reachability > >>>>>>> (state “-1”): one can’t signal two different states with a single > >>>>>>> signal. > >>>>>>> > >>>>>>> This seems easy to fix in the last version of the draft: one just have > >>>>>>> to signal state “-1” with the flags already defined and advertised. > >>>>>>> > >>>>>>> In short, negative reachability would be signal by advertising IP1 in > >>>>>>> TLV 135with a metric larger than 0xFE000000 and flag U (Unreachable > >>>>>>> Prefix) or UP (Unreachable Planned Prefix) set. > >>>>>> > >>>>>> that is exactly what the draft describes. I'm not sure what is your > >>>>>> point. > >>>>>> > >>>>>>> > >>>>>>> On the receiving side, state “-1” is learned from the reception of > >>>>>>> either flag. > >>>>>>> > >>>>>>> This is a very simple change, and it would address my concern. > >>>>>>> > >>>>>>> Can this be done? > >>>>>> > >>>>>> I'm not sure what exactly are you asking for as the draft is already > >>>>>> describing what you are asking for. > >>>>> > >>>>> [Bruno] Good if this is what is meant in the draft and if this is only > >>>>> misunderstanding. > >>>>> To be specific, I'm asking about the following changes for IS-IS > >>>>> (please feel free to reformulate, OSPF is up to you) > >>>>> > >>>>> §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. > >>>> > >>>> I don't think above is necessary: > >>>> > >>>> [RFC5305] defines the encoding for advertising IPv4 prefixes using 4 > >>>> octets of metric information. Section 4 specifies: > >>>> > >>>> "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. " > >>> > >>> Agreed with the quote. > >>> > >>> "prefix NOT considered during normal SPF computation" does not > >>> change/affect the outcome of the SPF computation. Hence does not remove > >>> reachability if a covering prefix is present. > >> > >> right. And UPA treatment is no different. It is only used to signal > >> unreachability to apps that are interested. It does not change anything > >> in forwarding itself. > > > > UPA changes/stop forwarding to BGP prefix using the UPA prefix as netxt-hop. > > This is a change in forwarding. > > ##PP > If the egress PE goes down BGP would move away to alternate NH - all we > do with UPA is to let BGP know sooner. Processing of the UPA is optional > and you are free ignore it and wait till the BGP finds out the remote PE > is dead. I see no backward compatibility problem here. > > > > > >>> > >>> Plus at the beginning of this email, you agreed that this signaling > >>> translate into state "0". (absence of reachability signal) > >>> I don't see how you can now say that this signaling translate in state > >>> "-1" (negative reachability) > >>> > >>> > >>>> As a result of the above, from the IP routing perspective, prefix with a > >>>> metric larger then MAX_PATH_METRIC (0xFE00000) MUST be treated as > >>>> unreachable. > >>> > >>> a) This prefix is absent in the RIB/FIB (just like if it were not > >>> advertised in TLV) > >>> b) Covering prefix is in the RIB/FIB. > >>> c) Net result is (positive) reachability. > >>> > >>> Could you point to the line(s) that you disagree with? > >> > >> I agree, and exactly same happens with UPA in terms of forwarding. > > > > Let's have IP2 being a BGP prefix having IP1 as BGP NH > > > > Today, if IP1 is advertised with a metric larger then MAX_PATH_METRIC > > IP2 is forwarding.to IP1 > > > > With UPA, if IP1 is advertised with a metric larger then MAX_PATH_METRIC > > IP2 stops forwarding to IP1 > > > > So the exact same signaling is triggering different/opposite behavior > > > > I would call this a change in the spec. And not backward compatible > > ##PP > please see my above response. > > > > > > >> > >> > >>> > >>>> If the implementation does not do that, it is clearly > >>>> violating RFC5305. > >>>> > >>>> We added the new flags, to distinguish from other cases where the prefix > >>>> might be advertised with metric higher than 0xFE000000, whatever that > >>>> use case is. But the meaning of the metric higher than 0xFE000000 from > >>>> the IP routing perspective does not changes by the new flags. > >>> > >>> This is exactly the concerned that I raised in my original email. (the > >>> one you did not see the difference between my point and the draft). > >> > >> I'm still not clear what is your concern. > > > > Let's have IP2 being a BGP prefix having IP1 (PE1) as BGP NH > > Today, in order to trigger a periodic or on-demand monitoring of this PE > > (e.g. BFD, ping, sr-mpls monitoring (rfc8403)..) I periodically advertises > > IP1 with a metric higher than 0xFE000000. This triggers on a centralized > > (or distributed system) the monitoring toward PE1. > > I'm free to do this and this is by the spec. > > > > With UPA, this would suddenly trigger unreachability signaling to this PE, > > breaking IP2 forwarding to PE1. > > ##PP > so you are saying that you can use metric higher than 0xFE000000 for > your monitoring case, but not for UPA?
##Bruno My usage does not affect BGP routing. UPA does. > Any usage of such metric was > non-standard so far. ##Bruno I would argue that the use and consequences of metric higher than 0xFE000000 is well specified in RFC 5305. > > For UPA we defined flags to signal the UPA case for such metric usage, > which distinguishes it from your "unspecified" case. As a result UPA > does not conflict with your private use of such metric. ##Bruno " U-Flag and UP-Flag are optional flags that have informative character." They can't be relied upon to distinguish the UPA case. > > I'm calling this a non-backward compatible change. > > ##PP > I'm not sure I see the backward compatibility issue here, given that UPA > can be distinguish from any other private use case of the metric higher > than 0xFE000000. ##Bruno How can the receiver distinguish UPA signaling from other uses of metric higher than 0xFE000000? (flags are not reliable, see above). All I'm asking is to make such Flags mandatory, and the UPA signal. (metric 0xFE000000 being only the transporter) Thanks, --Bruno > thanks, > Peter > > > > > Thanks, > > --Bruno > > > >> > >> thanks, > >> Peter > >> > >>> > >>> Thanks, > >>> --Bruno > >>> > >>>>> > >>>>> §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 of 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 the > >>>>> necessary functionality without the need for any protocol extensions. > >>>>> The functionality being described is called Unreachable Prefix > >>>>> Announcement (UPA). > >>>> > >>>> please see my above response. The treatment of the metric higher that > >>>> 0xFE000000 and LSInfiity has been defined long time back and is not > >>>> affected by the newly defined flags. > >>>> > >>>> thanks, > >>>> Peter > >>>>> > >>>>> Thank you, > >>>>> Regards, > >>>>> --Bruno > >>>>> > >>>>>>> > >>>>>>> The drawback is that the existing pre-standard implementation would > >>>>>>> need > >>>>>>> to be updated. But that’s the rule for a pre-standard implementation. > >>>>>> > >>>>>> not really, the handling of the metric higher that 0xFE000000 is > >>>>>> already > >>>>>> defined in the existing spec. > >>>>>> > >>>>>> regards, > >>>>>> Peter > >>>>>> > >>>>>>> > >>>>>>> The faster we do the change, the easier it is, especially for other > >>>>>>> implementations. > >>>>>>> > >>>>>>> --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
