[Lsr] Request for Working Group Adoption: Area Proxy

tony.li@tony.li Thu, 04 June 2020 16:42 UTC

Return-Path: <tony1athome@gmail.com>
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 E27403A0ADE for <lsr@ietfa.amsl.com>; Thu, 4 Jun 2020 09:42:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 dX93E9Z8sbkV for <lsr@ietfa.amsl.com>; Thu, 4 Jun 2020 09:42:50 -0700 (PDT)
Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (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 BC1063A0ADF for <lsr@ietf.org>; Thu, 4 Jun 2020 09:42:50 -0700 (PDT)
Received: by mail-pj1-x1036.google.com with SMTP id jz3so1356563pjb.0 for <lsr@ietf.org>; Thu, 04 Jun 2020 09:42:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:mime-version:subject:message-id:date:to; bh=n8xd/KjVacCPOHACBo38xZMbL8s5zllw0h7zhUF3Wjs=; b=dIvplbw1qG9JQ64PWnlEqn38RTyl6TeK5TSeyMx5XQwoZ54wy06gVOvC9i06+443ru nDAghKdA03xCFycMU3sCwpDaVNMjhggHjKLprZXd9+UQZKo+8Q/Gq5NHXSPo3WoCYV08 S8io5fQpwJVSgQf/8FhVYsMtFOAcoe807oAVA53n8DJEJI5gI9o8iiGOIm2dNRnBK2Gp Vzr92MMzyrdHoTZTxjSQkc2ow9lGF5dIs2VxBpuGGTgYQO9LfAn+J1Cjm1L2yyP1oCno 6/dZ6tdqUnXEcNWh7n/x3VOEkhTH4x31qUh6IVzEuospb8iYVanPMycaVlX10jdOMf9M 4IJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:mime-version:subject:message-id:date :to; bh=n8xd/KjVacCPOHACBo38xZMbL8s5zllw0h7zhUF3Wjs=; b=otPnEhOFukxlj2poOmJCpr6suzMLR9hszgG+GhfBVo+AkYF7YllrWMHa29+bVJErU8 yfq4RVN1Z8MYCHa357183FDiCR/N9+9oR7iwZqZKPBz5Q5YyEM+dgkhoFES/ceyEFu0g fFcHj72mvhpPxeCrZdVGhVGPEhcsbb4D3EUeYbOm9jxneaaJmQdDiXHnDdsO78VGDoU8 COhFbAzk7KR0DBxq9RjlZ+NKyKlhSyXEokXrFvkC5cuJz9oGyOeGG8UOpY50NVmCjHJm 44wRHwTpE1n4XZMeJ9vmhPInqG2BCkQ7IN1mR+4mE/dKJ55klfKib85Yu6RlatsI6Pfr mgHg==
X-Gm-Message-State: AOAM533HlqSJpQi+IhWH19xVQZTtGBiXh6oQ5lboJJqSVU8ViYN7LJbG +59ZscR7TXaoYEQgdNwiyEwLIRhS
X-Google-Smtp-Source: ABdhPJz6hRFQtEK9xyv3tOy+tf19M1Du+h+2gOLbpIDHAlF9Di/7Xp4wW1A/Lua5TTBC76atadaRPg==
X-Received: by 2002:a17:902:8a85:: with SMTP id p5mr5238451plo.253.1591288969649; Thu, 04 Jun 2020 09:42:49 -0700 (PDT)
Received: from [10.95.83.65] ([162.210.129.5]) by smtp.gmail.com with ESMTPSA id 25sm5704465pjk.50.2020.06.04.09.42.48 for <lsr@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jun 2020 09:42:48 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
From: tony.li@tony.li
Content-Type: multipart/alternative; boundary="Apple-Mail=_A4239551-4030-41DB-AF33-505FC56DD48E"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Message-Id: <BAD13DBC-8FA2-4722-9C00-327F59C5F6C7@tony.li>
Date: Thu, 4 Jun 2020 09:42:47 -0700
To: lsr@ietf.org
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/8WemVxeCmnD3eAzFs9_grtsxwW0>
Subject: [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 16:42:53 -0000

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 <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 <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 <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