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 ? > 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 ? 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 >>>> >>>> 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/ >>>>> >>>>> >>>>> >>>>> 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]
