Re: [Lsr] 答复: LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

tony.li@tony.li Thu, 15 August 2019 14:40 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 B2943120090 for <lsr@ietfa.amsl.com>; Thu, 15 Aug 2019 07:40:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 EoXFlL7qTQ6m for <lsr@ietfa.amsl.com>; Thu, 15 Aug 2019 07:40:40 -0700 (PDT)
Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 722FE120052 for <lsr@ietf.org>; Thu, 15 Aug 2019 07:40:40 -0700 (PDT)
Received: by mail-pg1-x536.google.com with SMTP id d1so791099pgp.4 for <lsr@ietf.org>; Thu, 15 Aug 2019 07:40:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4gtBDnm6G71UCjW2GTbNo7+ku9iCT6085k9P2tPn9rQ=; b=mLUdhiBYBxQYwLq6+tX/9zHwKLm9T+oTxRd1A1CwYgysM5lpjHqcc9sdhuqh1etNMv 1Wyu4udPfv1sO+gtKS7Yw0RsA/HJSzpeE1m+ffzu3+/lXgwpcDD4D5ow9JPIP2Ch5zCe IyKkA6Z8BgSpJHHQVMR6yh9BQRbZ5I2ATsm6wyY23dXQyUlDyiuZvuWk1l2cnVokjG5G CyjeMajUE4Pdtm+QoHQlcaFNDWUCu7O+h+v2P+iWBbjJ5KQT/C+uXDeVWU/t+CP+7oEm CPDQVTqeX3JlqtqoEFVZH0ywxWyAMujwq6RshtfLR7cvgPGHUGejaxgUe39u2MYO0kd9 5hRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=4gtBDnm6G71UCjW2GTbNo7+ku9iCT6085k9P2tPn9rQ=; b=gkel84gcHUeARLv3KnazWFnK1+aVIyNC9Sh442bqRiK2XGWAa4liVrkxrVjcbNGdLr i0gpwe3wYw8FIbdOsoF2mbE01DH9Bww9F+btB1OUY2D8+RwUXpRLNqqyFN37vUHlerLp kPLk5waY32Mjpj1JRQm0uy06+pkESNeg43NzPf9galUGyhyjBDOBvFGxiU1wD4fhLbhT 3NpaoadF/u1tBRv4xB5ZMuktaKukgLjG4v1dqXd5alNA+xBTcfNAVOoGuTgAbO/rSXYR AC2xk2hHOVzhKJoBSVqLcQQTnixgpn7LShUYeJUFPjvhrIRfDAd+qRsV4HitRQ4XEKBS jeRw==
X-Gm-Message-State: APjAAAVvN9C82Xp8dmgi1IUz4wrxZtmguIYZ/v2UBdXYaVdXDccsFfVL ts/qu8g6QZyuAMLyZTajJL0=
X-Google-Smtp-Source: APXvYqwjSS3QAxdC6SXFPW075I55cKSVwFlH+C693s2vUkxL+6xJrCAMSzHd8/vMB8xjRolDTmH4Jg==
X-Received: by 2002:a17:90a:234f:: with SMTP id f73mr2589105pje.130.1565880039761; Thu, 15 Aug 2019 07:40:39 -0700 (PDT)
Received: from [192.168.1.3] (c-73-158-115-137.hsd1.ca.comcast.net. [73.158.115.137]) by smtp.gmail.com with ESMTPSA id e7sm3169187pfn.72.2019.08.15.07.40.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Aug 2019 07:40:39 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
From: tony.li@tony.li
Message-Id: <C90AD13E-1512-4373-9CF7-32BAD6D65EC6@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F3B083A9-1478-4D88-93BC-CC62A4EEC757"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 15 Aug 2019 07:40:37 -0700
In-Reply-To: <01a501d55338$945c2b40$bd1481c0$@org.cn>
Cc: "Acee Lindem (acee)" <acee@cisco.com>, lsr@ietf.org
To: Aijun Wang <wangaijun@tsinghua.org.cn>
References: <8BAFFDB4-62B0-4018-966E-6861D89D0BD1@cisco.com> <01a501d55338$945c2b40$bd1481c0$@org.cn>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/_YAk6HgrTmrjiTMI3gpUHh4tzCA>
Subject: Re: [Lsr] =?utf-8?b?562U5aSNOiAgTFNSIFdvcmtpbmcgR3JvdXAgQWRvcHRpb24g?= =?utf-8?q?Call_for_=22Hierarchical_IS-IS=22_-_draft-li-lsr-isis-hierarchi?= =?utf-8?q?cal-isis-01?=
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, 15 Aug 2019 14:40:43 -0000

Hi Aijun,

> 1. The size of network is increasing, but it is becoming more flat. Is it the right direction to make the network more hierarchical? 


Well, given that we’re talking a link state protocol running SPF over a database in O(n log n) time, it’s pretty clear that we don’t want to scale the size of an area indefinitely. While modern processors are amazing (especially to those of us that started off with KHz 8080’s), it’s pretty clear that Moore’s law is over and that we cannot expect infinite compute power anytime in the future.  The alternative is to partition the network in some way.  Once partitioned, hierarchical arrangement seems like a natural fit. It’s been said that the only real tool that we have over scale is hierarchy.  Divide and conquer.


> 2. More hierarchical network means the traffic will also be traversed in hierarchical way, is it more efficient?


The hierarchical arrangement of the control plane does NOT imply that the data plane is necessarily hierarchical.


> 3. Is there any other methods to scale out the IS-IS deployment?


If you’ve been following along, Dynamic Flooding (https://tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-03 <https://tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-03>) allows us to address the limitations that we have with flooding, allowing us to scale the size of an area. However, it does not address the O(n log n) cost of SPF that will still ultimately bound the growth of areas and in turn necessitate more hierarchy.

Regards,
Tony