Re: [Lsr] Request for Working Group Adoption: Area Proxy

Robert Raszuk <robert@raszuk.net> Thu, 04 June 2020 23:23 UTC

Return-Path: <robert@raszuk.net>
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 0A1983A10A0 for <lsr@ietfa.amsl.com>; Thu, 4 Jun 2020 16:23:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 OvtTS6ndDbPn for <lsr@ietfa.amsl.com>; Thu, 4 Jun 2020 16:23:36 -0700 (PDT)
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74AEE3A106F for <lsr@ietf.org>; Thu, 4 Jun 2020 16:23:35 -0700 (PDT)
Received: by mail-ej1-x62a.google.com with SMTP id k11so7963859ejr.9 for <lsr@ietf.org>; Thu, 04 Jun 2020 16:23:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AAr1TO0+IWEjhgTmAP5FXrordCaQ3948BoPUDSwRRZk=; b=QRh/63kwrs+KAWc9UPCsajCh1Ye+okiju4nvVHnSuU+1cH+2fNGp39hbPecyjlHgXH X1N8HvuyBZ2/KSXtdLknj8HlNBkV6M21mg/sZ3b+Fd8GnUEDQbblK785wlTWIiTkphHo ZbK4pHI+9Pkib3H1ww+c8XozOVjlBE7UqSbkDxokPPsutgpqtx7x8YEmk4bPN/zMCYMW CNoIQIA/kfXw9ynP+sRUM2BlM3U/V6CuT4m67ft+kVAT3WPLFvVS/htciy57EQnwlokb t6BZ/ZTbracC/fsTnUj8Q4CzTp1PUQaY48P5qmbXEpKOLarYEbB+gv3JVyEpLVm51v5I bItw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AAr1TO0+IWEjhgTmAP5FXrordCaQ3948BoPUDSwRRZk=; b=JiVctTyrbzMvAOTlDSLl/vnrnCnYI8PDjiA5wnaY2MIFccEbnlYxNCnubSUam9MGfu K8fEN9vAz8zJiebOA492VyjpLCoaGvxGStnU7WnIM0V/pDHwToMNEHe04StubCl/wehU NLHS0c3c6bpjOjYgD/GhrQqQLRGHez8oSFXo3dQ805KwFGL3L11uSaWF4uadnqkditiZ VeV70FecB25PCECSstInSDTgPS3fLHmTVRjAIlLZZi6emfaISLE2rnuRPkJgArnsYIs7 mhCY5Nyd+5/l+efHffoIpiiFslpJjwXLXj3T1tFDyQY1hKd3tTTPyDG37nkiPQ+eHUS4 ZZvQ==
X-Gm-Message-State: AOAM533txWGiqmU02t2wrCiOBDV4KzIKVTSwIxgrtTDfH1GOIQeOX4GP E0SWwJXI8/b7TZSN8cKz+qRdh1aOzQfphufpAKZFjNjd
X-Google-Smtp-Source: ABdhPJyxRaoEoN8/0qpoF2Je3fAxw0ai2tWMkjbgd7Vw7Oxd8n3RB+XwmEHqysIDZ4Xngpoqla9cHxfM03Y6R1/kxx4=
X-Received: by 2002:a05:6402:6cc:: with SMTP id n12mr6396011edy.266.1591313013848; Thu, 04 Jun 2020 16:23:33 -0700 (PDT)
MIME-Version: 1.0
References: <BAD13DBC-8FA2-4722-9C00-327F59C5F6C7@tony.li>
In-Reply-To: <BAD13DBC-8FA2-4722-9C00-327F59C5F6C7@tony.li>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 05 Jun 2020 01:23:23 +0200
Message-ID: <CAOj+MMF5Q_FmNQfZ1D68Rdx5S6gkVxv9xiMn1rykRtqX2GbXuQ@mail.gmail.com>
To: Tony Li <tony.li@tony.li>
Cc: lsr@ietf.org
Content-Type: multipart/alternative; boundary="000000000000ead4b305a74a6e96"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/U1DFDp4qxrcCrCbnezFVZ6dFwKc>
Subject: Re: [Lsr] Request for Working Group Adoption: Area Proxy
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: Thu, 04 Jun 2020 23:23:45 -0000

Support.

Rgs,
R.

On Thu, Jun 4, 2020 at 6:42 PM <tony.li@tony.li> wrote:

>
> Dear Gentlebeings,
>
> I would like to formally request working group adoption of “Area Proxy for
> IS-IS” (https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-03).
>
> The goal of this work is to improve scalability of IS-IS when transit L1
> areas are in use.  In legacy IS-IS, for the L1 area topology to be utilized
> by L2, part of the topology must be configured as both Level 1 and Level 2.
> In the case where the transit topology is most or all of the L1 area, this
> creates a scalability issue as the size of the L2 LSDB approaches that of
> the entire network.
>
> We propose to address this by injecting only a single LSP into Level 2. We
> call this the Proxy LSP and it contains all reachability information for
> the L1 area plus connectivity from the L1 area to L2 adjacencies. The
> result is that the L1 area is now opaque, reachable, and fully capable of
> providing L2 transit.
>
> Our use case is the deployment of Clos topologies (e.g., spine-leaf
> topologies) as transit nodes, allowing these topologies to replace
> individual routers. We also see applications of this approach to abstract
> entire data centers or POPs as single nodes within the L2 area.
>
> There are two other proposals of note before the working group.
>
> In Topology Transparent Zones (
> https://tools.ietf.org/html/draft-chen-isis-ttz-08), an area (or zone)
> may be represented by a single node or as a full mesh of tunnels between
> the edges of the zone. In addition, there is a mechanism to attempt to
> seamlessly enable and disable the effectiveness of the zone. Relative to
> our proposal and for our use cases, the full mesh of tunnels is not as
> effective at providing scalability. In the specific case of spine-leaf
> networks, the leaves are typically the majority of the nodes in the
> network. As they become the edges of the area, with the full mesh approach,
> the majority of the area is not abstracted out of the L2 LSDB. For our use
> case, we have concerns about enabling and disabling the abstraction
> mechanism. There is added complexity to support this mechanism. In networks
> at scale, disabling abstraction may cause scalability failures. Enabling
> abstraction may cause failures as LSPs age out at dissimlar times. We feel
> that establishing abstraction is fundamental to the architecture of the
> network and that changing it on the fly is a highly risky operation, best
> suited for maintenance windows. Accordingly, the additional complexity of
> the transition mechanism is not required.
>
> In IS-IS Flood Reflection (
> https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01),
> abstraction is achieved by mechanisms similar to ours, but transit service
> is achieved by tunneling transit traffic. That’s not necessary in our
> propsal.  In Flood Reduction, the also is coupled to the flooding
> reduction, whereas in our proposal, the two are independent, tho they do
> share the Area Leader mechanism.
>
> While both of these proposals are very worthy, we believe that our
> proposal has substantial merit. We ask that the WG adopt Area Proxy for
> further work.
>
> Regards,
> Tony & Sarah
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>