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. Thx, Robert On Tue, Apr 22, 2025 at 11:29 PM Robert Raszuk <rob...@raszuk.net> 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= > 40cisco....@dmarc.ietf.org> 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 <yingzhen.i...@gmail.com> >> *Sent:* Thursday, April 17, 2025 11:13 AM >> *To:* lsr <lsr@ietf.org>; lsr-chairs <lsr-cha...@ietf.org> >> *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 -- lsr@ietf.org >> To unsubscribe send an email to lsr-le...@ietf.org >> >
_______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
