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. 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> To: "Les Ginsberg (ginsberg)" <[email protected]> >>> Cc: Gyan Mishra <[email protected]>, lsr <[email protected]> >>> 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 >>> [email protected] >>> 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 [email protected] https://www.ietf.org/mailman/listinfo/lsr
