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

Christian Hopps <chopps@chopps.org> Sun, 07 June 2020 00:56 UTC

Return-Path: <chopps@chopps.org>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0346B3A0831 for <lsr@ietfa.amsl.com>; Sat, 6 Jun 2020 17:56:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDnaS72aT8ct for <lsr@ietfa.amsl.com>; Sat, 6 Jun 2020 17:56:03 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id D003E3A082F for <lsr@ietf.org>; Sat, 6 Jun 2020 17:56:03 -0700 (PDT)
Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (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 465266085E; Sun, 7 Jun 2020 00:56:03 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Christian Hopps <chopps@chopps.org>
In-Reply-To: <B53A7AAF-171B-4186-8486-069BF9460797@gmail.com>
Date: Sat, 06 Jun 2020 20:56:02 -0400
Cc: Christian Hopps <chopps@chopps.org>, lsr@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <7E8C55E2-9657-4539-AD02-795AD7258F9F@chopps.org>
References: <790B898F-DB03-499E-BAAE-369504539475@chopps.org> <B53A7AAF-171B-4186-8486-069BF9460797@gmail.com>
To: Tony Li <tony1athome@gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/JcTjzSRpf5KwSLaT4PcHFGFHSXg>
Subject: Re: [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: Sun, 07 Jun 2020 00:56:05 -0000


> On Jun 6, 2020, at 5:15 PM, Tony Li <tony1athome@gmail.com> wrote:
> 
> 
> We’ve made some changes in the latest version of the draft.  In the current version, we require that each router in the area be L1L2.  However, only one LSP is advertised externally for each area.  Thus, each router will see 100 L1 LSPs, 100 L2 LSPs and 8 L2 Proxy 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.
> 
> 
> Doubling the number of areas would give you 16 L2 proxy LSPs, so you end up going from 208 LSPs to 216.  The key point here is that the database now scales linearly with the number of areas.

Ah yes, I missed that the Inside Edge Routers were masquerading using the Proxy System ID to the Outside Edge Routers. This does offer even better scaling.

This also does directly address your use case where the Area edge is very large compared to old designs.

Interestingly, if we consider Peter's pair of huge "R2" (L1L2 area edge) in Terastream (Telco Design), in effect you are creating a single Proxy LSP that continues to represent that concept topologically (although with a single "huge" router (Proxy LSP) rather than a pair of "R2"s), while allowing the huge multi-chassis physical routers to now be made up of N-many smaller physical routers.

On the industry direction, it'll be interesting to see if using N-many physical routers with all the external L2/L3 interconnect required and the extra operational/management costs actually works better than the single large multi-chassis with it's internal fabric interconnect that could be managed as a single router. It would seem to be adding a lot of operational cost on to the operator. Terastream was specifically trying to avoid this extra operational cost, as capex wasn't the problem, the opex was. Not having to forklift upgrade these huge routers was critical to that design though, and it sounds like maybe we're giving up on the vendors delivering on this?

Thanks,
Chris.
[as WG member]

P.S. Curiously, I had "fixed" my diagram and text just prior to sending the email as originally I had it as 108 L2 LSPs and then 216 when doubling the network, maybe I had noticed subconsciously. :)