HI Peter, Cool. So can you a bit reword this section 4 to make it clear ?
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]
