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]
