> On Jun 10, 2020, at 1:56 PM, Tony Przygienda <[email protected]> wrote:
>
>
>
> On Wed, Jun 10, 2020 at 10:29 AM Christian Hopps <[email protected]> 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,
Tony,
I think you have misunderstood me at some point. When asked about the
requirement of tunnels you said that they were not required, and that a
solution could be done with carefully scoped reachability, this was also
mentioned in your second presentation.
*ALL* I've been talking about WRT virtual links is that when you hint at a
non-tunnel solution in your draft and presentation involving reachability, that
your going to end up with OSPF virtual links. That is all.
Thanks,
Chris.
[as WG member]
> 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
>
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
