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

Christian Hopps <chopps@chopps.org> Sat, 06 June 2020 11:18 UTC

Return-Path: <chopps@chopps.org>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 58EB43A078C for <lsr@ietfa.amsl.com>; Sat, 6 Jun 2020 04:18:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id j8jr0RlhR4jG for <lsr@ietfa.amsl.com>; Sat, 6 Jun 2020 04:18:56 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org []) by ietfa.amsl.com (Postfix) with ESMTP id 842C13A078A for <lsr@ietf.org>; Sat, 6 Jun 2020 04:18:55 -0700 (PDT)
Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id BE1B760952; Sat, 6 Jun 2020 11:18:53 +0000 (UTC)
From: Christian Hopps <chopps@chopps.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0A215010-6D5A-4531-8861-40FD8EC53636"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Message-Id: <790B898F-DB03-499E-BAAE-369504539475@chopps.org>
Date: Sat, 6 Jun 2020 07:18:52 -0400
Cc: Christian Hopps <chopps@chopps.org>
To: lsr@ietf.org
X-Mailer: Apple Mail (2.3608.
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/7YyOqVMiPvK9Z6NwAV8Z6g0jC-c>
Subject: [Lsr] Thoughts on the area proxy and flood reflector drafts.
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Jun 2020 11:18:59 -0000

[ all the following is as a WG member ]

I've been thinking a lot about the proposed flooding reduction drafts currently vying for adoption by the WG. I've been doing this thinking in the context of wearing an operator hat (i.e., trying to leverage my prior experience working for DT on Terastream). In the abstract the Terastream architecture presented a good way to visualize and compare the benefits of using one of these solutions w/o getting too complex. A simplified model of this design can be seen as a horseshoe of horseshoes. the Major horseshoe is L2 and the minor horseshoes are L1. Each L1 area has 2 L2 routers for redundancy (I'll consider more though), and all L2 routers are full-mesh connected to support that redundancy.


But let's map this to a more DC centric view (I guess?) where each L1 area now has 10 L2 routers instead of 2 (i.e., 10%, but that could be change that later if need be).

Natural Design

Now for whatever reason some operators do not want to provision high-bandwidth transit links between their L2 routers in their L1 areas. This is critically important b/c otherwise you would simply use the above Natural Design. I'd like to better understand why that isn't just the answer here.

Anyway, forging ahead, here's what we get with unchanged IS-IS to support "use everything for transit"

All In

So the 800 L2 LSPs, and the impact on flooding dynamics, are what these drafts are trying to reduce or avoid.

Area Proxy

First I'll look at area proxy. This seems a fairly simple idea, basically it's taking the now L1L2 areas and advertising them externally as a single LSP so the impact is very similar to if they were L1 only. This maps fairly closely to the Telco and Natural Design from above. Each L1 router in the Telco design would have 100 LSPs The L12 routers would have 100 L1 + 16 L2 LSP. In the Natural Design each L1 router has 100 L1 and each L12 router would have 100 L1 and 80 L2. With Area Proxy each router  has 100 L1 and 100 "Inner L2 LSPs" and 80 "Outer LSPs" + 8 "Outer L2 LSPs"

The key thing to note here is that if you double the number of areas you only add to the Outside LSP and Proxy count just as it would scale in the Natural Design, so going from 8 to 16 areas here adds 80 more "Outside LSPs" and 8 more L2 Proxy LSPs for a total of 276 L2 LSPs even though you've added 800 more routers to your network.

Flood Reflectors

I'm less sure I understand this draft so please forgive me if I get this wrong. After reading this draft a few times I believe it is basically providing "L2 virtual links" over an L1 area between the area's L2 edge routers and then using a "flood reflector" to reduce the number of required "virtual links" by creating a hub-and-spoke topology of them.

The draft does a bit of hand-waving at "judicious scoping of reachability" being used in place of tunneling. I could guess at what this might mean, but I shouldn't have to; the draft should spell it out so it can be judged as a viable option or not. So, the only choice I see presented is to use a full-mesh of L1 tunnels between the L12 edge routers.

Anyway, here's a picture

If, in fact, the draft is talking about adding virtual links to IS-IS I think it should say that. There's a lot of experience in OSPF with virtual links and some of the trouble they have caused. There's also important details in making them work right in OSPF that doesn't seem to be in the current draft, so it's not clear what actual level of complexity is going to be required to make this all work, and importantly, if that would then be palatable.

I also do not like the idea of all of these automatic "fowarding-tunnels". They would be disjoint from the advertised "flood reflector" tunnel topology (right?) -- it seems like a management/debugability nightmare to me, and I'm curious which operators are keen to have a bunch of unadvertised tunnels added to their IGP network. :) If the draft really can work in general w/o the tunnels I would appreciate seeing those mechanics described rather than just hinted at.

The ideas are interesting for sure, but the draft doesn't seem fully fleshed out, and I'm worried it'll be overly complex when it is.

[as WG member]