Re: [Lsr] Thoughts on the area proxy and flood reflector drafts.

[Tony Przygienda <[e-mail]>]

On Wed, Jun 10, 2020 at 10:29 AM Christian Hopps <[e-mail]> wrote:

>
>
>
> >
> >
> > Hmmm, AFAIR the implementation of OSPF virtual links was having no
> tunnel at all (and that's how I remember I implemented it then). I cite
>
> Correct, that's why I'm suggesting that any solution without tunnels is
> going to reduce to OSPF virtual links.
>
>
Good to hear you implemented virtual w/o tunnels.

But then FR is not a solution "without tunnels" so the whole logic of "it's
not the same hence it's the same for me" escapes me completely now and I
let it rest.


>
>
> If it seems like I'm "carrying the torch" it's b/c as I understand the
> drafts currently, the area proxy seems like a much simpler solution (KISS),
> and I haven't yet been able to figure out what the benefits of using the
> flood reflector method instead would bring. If those benefits were more
> obvious I'd probably like it too. :)
>
>
looking @ the amount of protocol extensions in terms of TLVs, flooding
scoping, configuration etc necessary in either case and involved
fork-lifting, new-constructs necessary in operational tooling I dare say
you hold a somewhat unique "opinion" IMO ...

As to simplicity you see and since your mental model seems fixed around
virtual links concept, I also suggest to look up why in PNNI we ended up
introducing a special "L1 equivalent" computation to the peer group leader
to validate that it was actually reachable for correct operation
(especially hierarchy negotiations) on peer group egresses which in a sense
was like but worse than virtual links operationally IME. I was suggesting
then to keep an SVC from PGL to every border for that reason since a
partition of a PGL led otherwise to the peer groups looking like the same
thing for a while with highly undesirable operational effects (my memory
doesn't reach that far really but we had at least discussions then to
implement proprietary solution in Fore to have such SVCs for more stable
deployments). In more abstract terms, flooding is extremely good to quickly
"route around failures" when e'ones state is completely decentralized but
is simply not a great mechanism if you have to talk to an entity couple
hops away in a stable manner, especially if this entity hold state you need
for correct operation when talking to your peers.

-- tony