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

Robert Raszuk <robert@raszuk.net> Thu, 15 August 2019 14:56 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 1586D1200C1 for <lsr@ietfa.amsl.com>; Thu, 15 Aug 2019 07:56:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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: 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 b18-sFnP9YB8 for <lsr@ietfa.amsl.com>; Thu, 15 Aug 2019 07:56:50 -0700 (PDT)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 D4CE3120071 for <lsr@ietf.org>; Thu, 15 Aug 2019 07:56:49 -0700 (PDT)
Received: by mail-qt1-x82f.google.com with SMTP id t12so2603201qtp.9 for <lsr@ietf.org>; Thu, 15 Aug 2019 07:56:49 -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=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; d=1e100.net; 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: <8BAFFDB4-62B0-4018-966E-6861D89D0BD1@cisco.com> <01a501d55338$945c2b40$bd1481c0$@org.cn> <C90AD13E-1512-4373-9CF7-32BAD6D65EC6@tony.li>
In-Reply-To: <C90AD13E-1512-4373-9CF7-32BAD6D65EC6@tony.li>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 15 Aug 2019 16:56:38 +0200
Message-ID: <CAOj+MMFNkVbgbN1v7Q_4PBfLVN=Me_whcR36Um-Eu_AgSDF4Xg@mail.gmail.com>
To: Tony Li <tony.li@tony.li>
Cc: Aijun Wang <wangaijun@tsinghua.org.cn>, lsr@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004b09e6059029157b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/GSLhdd55kU4bt3edNoGY9yA8HM8>
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-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: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
failed.

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 ?

Thx,
R.

On Thu, Aug 15, 2019 at 4:40 PM <tony.li@tony.li>; 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 (
> 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
>
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>