Thx Shraddha, My point was to explicitly include both cases in section 4 OL and Max_Metric triggers for UP flag advertisement.
Current reading is that UPA should be injected only upon loss of reachability which is not the case neither with OL or Max-Metric. I think Peter agreed to adjust the text so I consider the topic as done :) Cheers, R. On Fri, Apr 25, 2025 at 8:07 AM Shraddha Hegde <[email protected]> wrote: > Robert, > > > > ABR can generate UPA for Planned maintenance based on OL bit. > > When it does, it can set the UP bit to indicate that. > > > > Hope that helps. > > > > Rgds > > Shraddha > > > > Juniper Business Use Only > > *From:* Peter Psenak <[email protected]> > *Sent:* 23 April 2025 19:54 > *To:* Robert Raszuk <[email protected]> > *Cc:* Les Ginsberg (ginsberg) <[email protected]>; > Yingzhen Qu <[email protected]>; lsr <[email protected]>; lsr-chairs < > [email protected]> > *Subject:* [Lsr] Re: WG Last Call for > draft-ietf-lsr-igp-ureach-prefix-announce (4/17/2025 - 5/2/2025) > > > > *[External Email. Be cautious of content]* > > > > Hi Robert, > > > > > > On 23/04/2025 14:57, Robert Raszuk wrote: > > Hi Peter, > > > > Say egress PE advertises Max_Metric which does not really cause > unreachability but least preference .. say before maintenance window > happens. > > > > So why wait till the ingress PE really goes down to trigger UPA from ABRs > ? > > > > If the egress PE is the only BGP NH, then reacting to max-metric or OL-bit > set would make some BGP destinations unreachable. > > > The prefix is still reachable and if the BGP selection on the ingress PE > uses the > > > IGP metric towards the NH as one of the rules for selecting the best > path, > > > the traffic will be rerouted to the alternate PE. > > > > See the entire problem is that ingress PE does not have that NH metric > visibility in egress PE area (it is sitting happily in it's own different > area on the other side of the planet) - hence it has no clue about what is > going to happen with egress PE in few moments ... > > > > So why not trigger UPA in such cases to hint him to switch to alternate > next hops if available ? > > I'm not saying it can not be done. The implementation can chose to > advertise the UPA for the summary component prefix if the such prefix > metric in the source area/domain crosses certain value or if the prefix > originator is overloaded. > > thanks, > Peter > > > > > > Thx, > > R. > > > > > > > > On Wed, Apr 23, 2025 at 2:50 PM Peter Psenak <[email protected]> wrote: > > Hi Robert, > > > > sorry, I misunderstood your original question. > > > > If the OL bit, or max-metric does not result in prefix becoming > unreachable on the ABR/ASBR that originates the summary covering the > prefix, there is no need to generate UPA. The prefix is still reachable and > if the BGP selection on the ingress PE uses the IGP metric towards the NH > as one of the rules for selecting the best path, the traffic will be > rerouted to the alternate PE. > > > > thanks, > > Peter > > > > On 23/04/2025 13:41, Robert Raszuk wrote: > > I would just suggest to make it explicit in this bullet: > > > > Instead: > > > > * - reachability of a prefix that was reachable earlier was lost* > > > > *say: * > > > > * - reachability of a prefix that was reachable earlier was lost or node > originating such prefix was signalled with OL bit set or MAX_METRIC set.* > > > > or something along those lines. > > > > Thx, > > R. > > > > On Wed, Apr 23, 2025 at 12:16 PM Peter Psenak <[email protected]> wrote: > > Hi Robert, > > > > > > On 23/04/2025 11:49, Robert Raszuk wrote: > > HI Peter, > > > > Cool. So can you a bit reword this section 4 to make it clear ? > > > > and what exactly is not clear and how would you suggest to reword it? > > thanks, > Peter > > > > Thx, > > R. > > > > On Wed, Apr 23, 2025 at 8:52 AM Peter Psenak <[email protected]> wrote: > > Robert, > > > > On 23/04/2025 00:44, Robert Raszuk wrote: > > All, > > > > I have one more question in respect to the text in the draft ... > > > > > > > > > > > > *4. Generation of the UPA UPA MAY be generated by the ABR or ASBR that > is performing the summarization, when all of the following conditions > are met: - reachability of a prefix that was reachable earlier was > lost - a summary address which covers the prefix is being advertised > by the ABR/ASBR* > > > > So with the above text in mind would we advertise UPA when: > > > > A) Operator manually sets overload bit on an egress PE ? (Technically the > node is still reachable) > > > > B) Operator manually forces to advertise within L1 max metric for its > router-LSA ? (Technically the node is still reachable) > > > > In both cases the second condition is met - summary covers the egress node > of the sare L1 or non 0 area. > > > > My reading of section 4 leads me to believe that the answer to both (A) > and (B) questions is "no" - and that would be perhaps something worth > revisiting. > > yes, UPA would be advertised. The point is that you want the ingress PE to > reroute if there is an alternative egress PE that can reach BGP prefix > located behind the PE where (A) or (B) was done. > > thanks, > Peter > > > > > > Thx, > > Robert > > > > > > On Tue, Apr 22, 2025 at 11:29 PM Robert Raszuk <[email protected]> wrote: > > Hi Les, > > > > Let's open a bit of imagination and assume one day we progress > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-extended-hierarchy-06 > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-extended-hierarchy-06__;!!NEt6yMaO-gk!AoBqOTZJ3HaV8ElNpI6iik5MptxvGOYSiZekweLxT90nDEmlczZ_07qQvP_5rqTQfn5_ei23k8xO9TibqBpQ6eYqMGt8BOvh$> > > > > Do you think this is wise to blast UPAs everywhere in all 8 levels > when perhaps it is needed only on a few egress nodes sitting in one > specific area of say level 4 ? > > > > I do understand your statement that since we are creating summaries we are > the problem and need to fix it but let's not forget that summaries are > created by operators and such operators can use other tools to signal holes > in them. Both droid and bgp based models have been discussed yet UPA is > being pushed. > > > > It seems that UPAs are example of very good marketing skills :). > > > > Cheers, > > Robert > > > > > > On Tue, Apr 22, 2025 at 4:35 PM Les Ginsberg (ginsberg) <ginsberg= > [email protected]> wrote: > > I support progression of the UPA draft. > > > > It leverages an existing mechanism in the protocols to provide needed > functionality - which has been proven viable by multiple implementations. > > > > As I have commented in the past, I do wish the definition of the flags was > modified so they were not mutually exclusive. This model leads to the > inability to add additional related flags in the future without creating a > backwards compatibility issue. > > > > Regarding concerns expressed by other WG members as to the appropriateness > and scalability of the mechanism defined here: > > > > I think the draft is careful in defining how the mechanism should be used > so > > as to avoid scalability issues. I also think no one has offered an > alternative which is more scalable. > > Given IGPs already advertise reachability, summaries, and unreachability, > this mechanism is clearly an appropriate use of the IGPs. > > > > Les > > > > *From:* Yingzhen Qu <[email protected]> > *Sent:* Thursday, April 17, 2025 11:13 AM > *To:* lsr <[email protected]>; lsr-chairs <[email protected]> > *Subject:* [Lsr] WG Last Call for > draft-ietf-lsr-igp-ureach-prefix-announce (4/17/2025 - 5/2/2025) > > > > Hi, > > > > This email begins a 2 week WG Last Call for the following draft: > > IGP Unreachable Prefix Announcement > > https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-ureach-prefix-announce/ > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-lsr-igp-ureach-prefix-announce/__;!!NEt6yMaO-gk!AoBqOTZJ3HaV8ElNpI6iik5MptxvGOYSiZekweLxT90nDEmlczZ_07qQvP_5rqTQfn5_ei23k8xO9TibqBpQ6eYqMFPeDnXF$> > > > > Please review the document and indicate your support or objections by May > 2nd, 2025. > > > > Authors and contributors, > > Please indicate to the list your knowledge of any IPR related to this work. > > > > Thanks, > > Yingzhen > > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > > > > > > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
