Tony P, > or black-holing on aggregates since we cannot "back-off" generic LPM packet forwarding when we > realize we're @ a dead end due to aggregation.
I hope you are not stating that aggregation is a bad thing here and all we should be distributing are host routes :) But to your point - IGP is a servant to the application/service which is BGP. So removal of BGP service routes in a topology independent fashion can be really fast and take one or two hops. Assume we detect failure of a remote node - I am not sure if BGP will withdraw service routes faster across two RRs or IGP will remove next hop by flooding via area over N nodes then crossing ABR or ASBR and flooding again over N nodes will be any faster. Last time I measured the speed of BGP transit of withdraw message via control plane only RR with decent BGP implementation it was in ranges of ms. Thx, R. On Mon, Jun 15, 2020 at 7:57 PM Tony Przygienda <tonysi...@gmail.com> wrote: > > > On Mon, Jun 15, 2020 at 10:37 AM <tony...@tony.li> wrote: > >> >> Hi Robert, >> >> >> > > It’s very clear that this is inadequate. >> > >> > Doesn't this really depend how you architect multiple levels ? Sure you >> have some physical topology - but it seems to me that the trick is in >> properly laying out levels on top of them and between them. >> >> >> The very pragmatic viewpoint is that network architects will construct >> the physical topology that best suits their traffic pattern and that trying >> to contort that physical topology into some kind of hierarchy will create >> additional (and perhaps significant) cost. People don’t want to do that. >> They want scalable networks that match their physical topology. For this >> to work, our hierarchical abstractions need to be independent of the >> topology and that forces us into having transit areas. >> >> >> > PNNI had transit areas in hierarchy working but the trick was connection > setup cranck-back. Such a thing would work for RSVP or any of the stateful > connection setups but alas, this is not fashionable right now. > Unfortunately, generic hierarchy with reachability summarization ends up > with very sub-optimal routing or black-holing on aggregates since we cannot > "back-off" generic LPM packet forwarding when we realize we're @ a dead end > due to aggregation. To prevent bi-furcation of topology or transit > horizontals several solutions exist, one of which (configure hierarchy > statically everywhere) the current draft has in now but alas, the topology > is star of stars (you can actually see CLOS conceptually as something like > this as well ;-) > > my meta 2c > > -- tony > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
