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

Robert Raszuk <> Thu, 15 August 2019 14:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1586D1200C1 for <>; Thu, 15 Aug 2019 07:56:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b18-sFnP9YB8 for <>; Thu, 15 Aug 2019 07:56:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D4CE3120071 for <>; Thu, 15 Aug 2019 07:56:49 -0700 (PDT)
Received: by with SMTP id t12so2603201qtp.9 for <>; Thu, 15 Aug 2019 07:56:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AUOERPycOz5CngcJ7j9xXmz7V4uh+9G3w4DB8I0dXfY=; b=B1CV/Uc2Yte/Xj2K/OyoQxM3Udi9eehzphlJKKeReK0l+NCwnQCRHCq4kLyDwHFfdU jvlJfAUGCg0sbnJKgps76eXirGl5A5ihU2xDgSxS8CTBLPnPiEYt+4NZsvbTdsfHs+kD zQGu6i9c3OKHSEbbgmzNcH2CTPkgn4N3TVmrId4eQmnEI2Hk5NMJYQbON0GbIjS2sJ1K lcoHNcxUllNFQjOfsATTca+W3cuUBW16x0qYet4Sy3QKtxnvDw8cddBSx06YHEkgMQnQ v6oyWX2Bd+agm2ylKhSn7nM17ApHbf2WLd9BOjJ0z3K9ICiI6YYh0YqxWv97lzBZ38Nx BTKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AUOERPycOz5CngcJ7j9xXmz7V4uh+9G3w4DB8I0dXfY=; b=Xol1MWzFrK1d9Ya4CcUQGEjPV5ThmtguOWTupvTqGhwSxe1rGrR1d9+b+5L0nvkAPV uCN7WxgDKb+wAzz6QlO+luNFa3hO0H/MAZEYJdgtMqPMiCKH5eUnZ/lZUqHvcoU7HHFS jz83iO/t2kSNwFJO1mOWZPUYFN8NzfUhRGdFDV6L37XptDXL6dGwwrtWO5TD3WVoQ8RH ylJpEx/DstpGzYWBJAKfstU7+qmq24l6R0xBhLjH6gkuHDpAwvS2nhH3HNJQgJtPYWEF Y3EOTFoo29xTYRbTQ3Dx8TwlD2zQbrkCwaNlnfT97sG+jLz00T1H30y6v2TTwRB2PhmY 25hQ==
X-Gm-Message-State: APjAAAWo+i/I8CbPtZw9fq8oAxeaYhXsLC/SZjwK+Db7iy4wWZU0xfFq KRsWqHPzIg368IpRZpUwZGfwblfOK0KxoSBP7yKFJA==
X-Google-Smtp-Source: APXvYqznuyYqzUHDxjdp0aFqkH8uDhAXFIWXKBJbpyeLNI5SwHSxyNkWupt0oQeXS1+EiM9JZqfXJEc4xKLdzgNUf5c=
X-Received: by 2002:aed:2667:: with SMTP id z94mr4486273qtc.343.1565881008845; Thu, 15 Aug 2019 07:56:48 -0700 (PDT)
MIME-Version: 1.0
References: <> <01a501d55338$945c2b40$bd1481c0$> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Thu, 15 Aug 2019 16:56:38 +0200
Message-ID: <>
To: Tony Li <>
Cc: Aijun Wang <>,
Content-Type: multipart/alternative; boundary="0000000000004b09e6059029157b"
Archived-At: <>
Subject: Re: [Lsr] =?utf-8?b?562U5aSNOiBMU1IgV29ya2luZyBHcm91cCBBZG9wdGlvbiBD?= =?utf-8?q?all_for_=22Hierarchical_IS-IS=22_-_draft-li-lsr-isis-hierarchic?= =?utf-8?q?al-isis-01?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Aug 2019 14:56:53 -0000

Hi Tony,

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

Since Aijun posted his question I was trying to think of such model, but

While it is easy to envision this with DV protocols say BGP - do you have
any pointer to a link state protocol architecture where data plane is non
hierarchical (links do not belong to upper levels) while control plane used
traverses multiple levels ?


On Thu, Aug 15, 2019 at 4:40 PM <> wrote:

> 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 (
> 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
> _______________________________________________
> Lsr mailing list