Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

[Tony Przygienda <[e-mail]>]

On Mon, Jun 15, 2020 at 10:37 AM <[e-mail]> 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