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

> On Jun 10, 2020, at 2:10 PM, Tony Przygienda <tonysietf@gmail.com> wrote:
> 
> 
> 
> On Wed, Jun 10, 2020 at 11:04 AM Christian Hopps <chopps@chopps.org> wrote:
> 
> ....
> 
> 
> > 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. 
> 
> 
> So we understand L2 tunnels from leaf to FR are "real" tunnels and have nothing to do with virtual links. 
> 
> As to the data plane, nope, you don't end up with any "virtual links" I can recognize unless you choose to call redistribution "virtual links" as well, maybe look @ the presentation again. 

That's exactly it! Excellent. :)

Safely using redistributed reachability to provide transit w/o tunnels is exactly what OSPF virtual links are, so that's why I'm saying

"A solution without tunnels is also possible by judicious scoping of reachability information between the levels."

will reduce to the same thing, if you want it to actually work generically. Perhaps this will become more obvious when that part of the draft is fleshed out.

Thanks,
Chris.

> 
> -- tony 
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr