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

[Christian Hopps <[e-mail]>]

> On Jun 10, 2020, at 1:56 PM, Tony Przygienda <[e-mail]> wrote:
> 
> 
> 
> 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,

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 
>