Hi Robert, From: Lsr <lsr-boun...@ietf.org> on behalf of Robert Raszuk <rob...@raszuk.net> Date: Friday, October 15, 2021 at 3:17 PM To: Enke Chen <enc...@paloaltonetworks.com> Cc: lsr <lsr@ietf.org>, Tony Li <tony...@tony.li> Subject: Re: [Lsr] Prefix Unreachable Announcement and IS-IS and OSPF Extension for Event Notification
Hi Enke, Yes each summarization/aggregation results in loss of some granular information for the benefit of scaling the overall system. The current discussion does not state that networks must use summarization but actually assumes that one has a hierarchical underlay spanning large geography (maybe entire planet) with lots of service edges. Maybe 1K, 10K .. maybe more when it comes to 5G Edges. 10K loopbacks advertised as summaries should be nothing for a will-tuned OSPF implementation. Most implementations (at least the ones I’ve worked on) support overlapping range configuration so you can have more specific summaries that are advertised. A nice additional configuration tool would be to have a range which would not result in a summary but routes falling in the range would just be advertised rather than aggregated. This would ease the configuration overhead as long network administrators had the forethought to put these loopback into a subset of the prefixes allocated to a given area. Thanks, Acee Then recommendation to say - pls go and flood all of those with leaking /32 or /128 everywhere seems not that great. But again I think service recovery should be done at service level as it is today in different failure scenarios. Thx, R. On Fri, Oct 15, 2021 at 8:25 PM Enke Chen <enc...@paloaltonetworks.com<mailto:enc...@paloaltonetworks.com>> wrote: Hi, Robert: The two cases I listed for requiring the individual loopbacks were the ones we faced at InternetMCI many years ago when we were investigating using both L2+L1 (prior to L2 route leaking). It's not sufficiently accurate to rely on the aggregates in these cases. Thanks. -- Enke On Fri, Oct 15, 2021 at 10:37 AM Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>> wrote: Enke, Not really ... unless you force it by configuration most specific route is used to resolve your next hops. Clearly everything works fine from your list with no loopbacks everywhere - except summary route is used instead. Best, R. On Fri, Oct 15, 2021 at 7:21 PM Enke Chen <enc...@paloaltonetworks.com<mailto:enc...@paloaltonetworks.com>> wrote: Hi, Folks: As I recall, the loopbacks and their metrics need to be propagated individually to the whole network (including leaking from Level 2 to Level 1) for the following reasons: 1) Path selection: in case there are multiple Level 2 / Level 1 routers in an area. 2) Export IGP metric : when the IGP metrics are exported to BGP as MED for symmetric routing. Not sure if there is still a problem to be solved. Regards, -- Enke ---------- Forwarded message ---------- From: Tony Li <tony...@tony.li<mailto:tony...@tony.li>> To: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> Cc: Gyan Mishra <hayabusa...@gmail.com<mailto:hayabusa...@gmail.com>>, lsr <lsr@ietf.org<mailto:lsr@ietf.org>> Bcc: Date: Wed, 13 Oct 2021 22:50:33 -0700 Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification" Les, If you’re advertising loopbacks that are outside of the summarized space, then you end up with reachability and liveness. Yes, there’s a cost in scalability… it ain’t free. Tony _______________________________________________ Lsr mailing list Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_lsr&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=CyuvZoeTxWdq-MzY_N3aRC3vN5iXMJzjHo_7TP5_S2U&s=aG7aHzcn05QWfjkWdJ4f05SYrO_kHYoA6h3LccwlysQ&e=>
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
