> On Jun 10, 2020, at 12:40 PM, Tony Przygienda <[email protected]> wrote:
>
>
>
> On Wed, Jun 10, 2020 at 4:27 AM Christian Hopps <[email protected]> wrote:
>
>
> > On Jun 9, 2020, at 10:01 PM, Tony Przygienda <[email protected]> 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
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
