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

[Tony Przygienda <[e-mail]>]

yepp, it's one philosophy and design point which I'm  quite well aware off
;-) and it's feasible of course that instead of a signalling protocol or
even SR the controller provisions all paths via e.g. PCE of course if one
can live with the delay and implications of large scale failures. If we
rely on controller fixing LPM as well under failures then really, who needs
IGPs anymore anyway except for bunch of loopbacks and SPF for the
controller to do all the FIB work and hence discussions like high
hierarchies or anisotropic routing are largely superfluous me thinks ;-)

-- tony




On Mon, Jun 15, 2020 at 11:01 AM <[e-mail]> wrote:

>
>
> On Jun 15, 2020, at 10:56 AM, Tony Przygienda <[e-mail]> wrote:
>
> 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 ;-)
>
>
>
> Hi Tony,
>
> The modern solution of choice is to relegate all of the traffic
> engineering to an out-of-band controller that no longer operates in
> real-time and has the scale to span levels and areas.
>
> Tony
>
>