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

[Christian Hopps <[e-mail]>]

> On Jun 10, 2020, at 12:40 PM, Tony Przygienda <[e-mail]> wrote:
> 
> 
> 
> On Wed, Jun 10, 2020 at 4:27 AM Christian Hopps <[e-mail]> wrote:
> 
> 
> > On Jun 9, 2020, at 10:01 PM, Tony Przygienda <[e-mail]> wrote:
> > 
> > Chris (addressing in WG member context you declared), I reply tersely since we will put more work into the draft once it's adopted (for which I think you saw a good amount of support in two threads already). 
> > 
> > I deferred from your email since the chain-terrasteam topology you're showing is simply not what we are dealing in any operational, successful networks today AFAIK frankly and I saw lots of "assume complexity" and "dislikes" in your email which I didn't read as technical arguments but mental attitudes. Likes or dislikes and assumptions are fine but we should probably focus on existing network/customer technical + operational arguments & requirements when building solutions and now what you or we like first. 
> 
> Both Area Proxy and Flood Reflector are proposing to use L1 areas as transit to connect L2, isn't that chaining? It seemed like a decent way to help visualize the proposals along with some numbers, perhaps you have something better...
> 
> The Area Proxy draft is making everything L2 and using the L1 areas to redefine the advertised topology information to allow it to scale. Because everything is ultimately L2 nothing changes in the data plane to provide this transit.
> 
> The flood reflector draft is keeping the L1-only abstraction so it has to provide for transit some other way.
> 
> > So trying to extract the technical point you seem to be making inbetween all that
> > 
> > a) I see how you can try to have a mental model of "virtual links". What we suggest are not virtual links (I implemented VL @ least once but it's so long ago I forgot pretty much all the details so had to look stuff up :-) Virtual links in OSPF were "magic bits on LSAs" that kind of computed "SPF reachability through the area to change SPF" edge-to-edge and the asynchronicity of all that flooding-being-tunnels-being-SPF was playing havoc on us @ this time of 300MHz CPUs + frankly, the complexity of that was not needed @ this time just as partition healing was never implemented in ISIS.. That's why it never went anywhere much, my take, others may correct. Saying "virtual links are bad" and "this is virtual links to me so it's bad" is simply a "strawman fallacy" to me frankly. This draft suggests (but as I wrote Bruno as answer to his fairly deep email) to run proper flooding over proper tunnels (we run routing over tunnels all the time in all kind of scenarios be it BGP proper or SD-WAN or overlays obviously) but if you choose FRs to be one hop away you can get away without any "L2 tunneled adjacencies", that's deployment choice. 
> 
> If you are not using tunnels, but are still trying to provide transit through the L1 area for L2, that is exactly what OSPF virtual links are doing. Part of making those work is the advertisement of reachability into the area from another, changes to router advertisements (to indicate if the area is transit capable), and changes to the SPF calculation to modify route choices based on whether they are based on virtual links or not.
> 
> The complexity of OSPF virtual links is there to make them work, right? I'm not trying to make any argument, strawman or otherwise; I'm just trying to understand what is being proposed as a replacement for the full-mesh of tunnels.
> 
> It's nice if it reduces to OSPF virtual links b/c we then have an example of how to actually implement it, and years of experience to understand it. If that highlights that getting the non-tunneled choice right isn't easy, well I guess that's important, right?
> 
> 
> 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.

:)

> 
> "
> The InterfaceUp event occurs for
>     a virtual link when its corresponding routing table entry becomes
>     reachable.  Conversely, the InterfaceDown event occurs when its
>     routing table entry becomes unreachable.  In other words, the
>     virtual link's viability is determined by the existence of an
>     intra-area path, through the Transit area, between the two
>     endpoints. 
> 
> "
>  and that was largely the problem, flooding+SPF+routing table was basically the adjacency keep up and very flappy/circular instead of proper stable tunnel with hellos. Did you implement and run virtual links in OSPF over tunnels? which type? 

Well I had to implement them (virtual links, not tunnels, since that's just how OSPF virtual links work) back in the day when I added the non-backbone code to the second GateD OSPF version. From that point on it was all IS-IS though. :)

> And having run good amount of routing over tunnels I am still to see all those dragons you are summoning. GRE, incl soft GRE is very widely deployed and works well as are other tunnel types I worked with. 

One solution requires tunnels the other doesn't *shrug*, tunnels aren't free they cost bandwidth and add complexity I think.

> You do seem to be carrying as WG member a hot torch for area-proxy for some reason,

Isn't that the point of me being able to contribute "as a WG member"? If I was saying all this "As a Chair" and/or acting on it "As a chair" by fiat, then it would be seen as unfair. We do want our chairs (who are generally knowledgeable about that for which they chair) to be able to contribute to a technical discussion though, right?

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. :)

Thanks,
Chris.
[as WG member]

> that's fine with me, frankly, I had extensive discussions with customers when DriveNet was being proposed to them (which AFAIS is basically area-proxy) and the solution is intriguing but it did not cut lots of requirements of large customers and there are a lot of unresolved issues operationally with an approach like that. However, I'm here to make sure to get flood reflectors adopted so it can be deployed by customers in ideally multi-vendor, interoperable scenarios and not on crusades so let's adopt the draft and then we fill the pieces in and maybe extend it to hierarchy, no-tunnel-one-hop-away bits if people think that is interesting/relevant and are willing to work on that.  And then customers can choose whether they run area-proxy or flood reflectors based on what requirement set is important to them. 



> 
> thanks
> 
> --- tony