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

Robert Raszuk <robert@raszuk.net> Fri, 16 August 2019 19:16 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 9E7C71200EB for <lsr@ietfa.amsl.com>; Fri, 16 Aug 2019 12:16:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, 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 W-oLVMMDdReA for <lsr@ietfa.amsl.com>; Fri, 16 Aug 2019 12:16:43 -0700 (PDT)
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 58606120052 for <lsr@ietf.org>; Fri, 16 Aug 2019 12:16:43 -0700 (PDT)
Received: by mail-qk1-x733.google.com with SMTP id r21so5664899qke.2 for <lsr@ietf.org>; Fri, 16 Aug 2019 12:16:43 -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=GLJ9RALMMoC+uTyWbo/5TzlWPnPEuCpMsWtBz6pwGlU=; b=M5n9e01n/r+F4lBt+oNHqILYxA4u5XXjQ+5GT7Hu94fBLreMW57Gm07j3dpjP1ThK9 /Req1Ed9Ph9qdZz/h/+6hN286u3xsOTXKL+yqswKZAviDftx961SJQdOWJU+4jkTYYSa Eol7CKl1q4kdFal0wrPY2BHQnSs62puLbFdCi9jGP1E9ktgCyx1OY6wDfehsdToDkx3Z iq/CFeQPA09F6jWOGQ9qvYDXk6kmFsAJzpHJDyDlUgn1N5RdbRYLR6IiQSDiuvV+Hw7e bGIJls+fOdHFzRHs46S2tnNLei7/YzDbJRPEMMlETvqgdHtuiQA+vok9RFQUWhP4JHCU HecA==
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=GLJ9RALMMoC+uTyWbo/5TzlWPnPEuCpMsWtBz6pwGlU=; b=he2IMfkCH3kkcmnsyb/w3oXVONIdac3KfLgDO8HpgPJDI2bJYgVTGFCiMSPxY9SN+6 8FRnfcdVhPbF1DoGOeQ2e0pybE7EOu5F3L8JCaeY7+Cs/4o50apgMS+JXZ0IG6Ddot1F dPqxb9oNDnXz8hckXFc7/rrMy+mUPro2rAW6tCFnRflbkLKC17/KXKRH9T6s0nZSxeGk qbn/2CNNs1zL9J39HQFAPf7HmEiKDPx0DYdTS+WJUwnIxqmFcDJwYYfdChdRubYj44fH ABwZXmGRVIjIrkWdf8/nevNqfzARb0n5jzIsRs8HsUV8oT5ieudCRROSuJDnpiYZ+QZr QZ9g==
X-Gm-Message-State: APjAAAU+8Ev2LGeIdTd6AC5ti32OILcEmLic2ZqnlcnvtQqqh/pVyuYT OSW0diTfMZ8+TdXLK9pnh2+Yq7WvDmJt7vY6ynmdRQ==
X-Google-Smtp-Source: APXvYqwl2jWCtQTYnirrig5P1xnxs8ix6a7GztSE9BBEclQkewO/yaphSX6WfSL4M4t4hAMf20avxhS7R7Sx7XH4C2M=
X-Received: by 2002:ae9:dd82:: with SMTP id r124mr10116144qkf.134.1565983002200; Fri, 16 Aug 2019 12:16:42 -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> <CAOj+MMFNkVbgbN1v7Q_4PBfLVN=Me_whcR36Um-Eu_AgSDF4Xg@mail.gmail.com> <24D935ED-28C3-4A84-B42C-E429EC2D6FE8@tony.li> <00b601d553fe$9636a5a0$c2a3f0e0$@org.cn> <DF25D566-1EC3-483A-BCE9-5C6EDDF74617@tony.li> <4ABA6852-23CB-4B11-9FB2-C4A643740441@tony.li> <BYAPR11MB363826C6814F96998F096F3AC1AF0@BYAPR11MB3638.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB363826C6814F96998F096F3AC1AF0@BYAPR11MB3638.namprd11.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 16 Aug 2019 21:16:32 +0200
Message-ID: <CAOj+MMGoqBS2jVCZrEsNs_+ymmjgwCDYd-dRBWaNGR_r9R71YA@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: "tony.li@tony.li" <tony.li@tony.li>, "lsr@ietf.org" <lsr@ietf.org>, Aijun Wang <wangaijun@tsinghua.org.cn>
Content-Type: multipart/alternative; boundary="00000000000092219b059040d48a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/PWLsR8wix3MNRBOyfoME-7ahRNg>
Subject: Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-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: Fri, 16 Aug 2019 19:16:47 -0000

Hey Les,

Of course the objective of the draft is clear and I do not think anyone is
questioning that. There was however topic of data and control plane
congruence requirement and I think we all agreed by now that this is rather
required in link state protocol as it is defined today.

As to the overall direction which I think initial Aijun's mail brought up
was if hierarchy is actually best answer to scale a protocol.

Divide and conquer is great strategy, but as such it could be realized with
flat levels interconnected by ISIS LSP reflectors as pure control plane
scaling solution (still reusing most of today's machinery - leaking,
summarization etc ...) Some form of DIS analogy except here to interconnect
many flat levels.

So I think the overall point to the WG is if building additional data and
control plane levels is the most optimal solution to scale link state
protocols up. Sure it can be done and it will be one more optional tool in
the toolbox, but is this the right/best tool for the job ?

Thx,
R.


On Fri, Aug 16, 2019 at 8:08 PM Les Ginsberg (ginsberg) <ginsberg@cisco.com>
wrote:

> To expand on this a bit, the point of the draft extensions is to add
> additional levels of hierarchy and use existing mechanisms (leaking,
> summarization) to have traffic flow up/down the hierarchy.
>
> The intent is NOT to bypass the hierarchy.
>
>
>
> People can use multiple instances and redistribution to do whatever they
> may wish. In that context two instances of IS-IS are no different then one
> instance of two different protocols.
>
> But this is decidedly NOT the intent of the draft.
>
>
>
>    Les
>
>
>
>
>
> *From:* Lsr <lsr-bounces@ietf.org> *On Behalf Of * tony.li@tony.li
> *Sent:* Friday, August 16, 2019 11:01 AM
> *To:* Tony Li <tony.li@tony.li>
> *Cc:* lsr@ietf.org; Aijun Wang <wangaijun@tsinghua.org.cn>; Robert Raszuk
> <robert@raszuk.net>
> *Subject:* Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical
> IS-IS" - draft-li-lsr-isis-hierarchical-isis-01
>
>
>
>
>
> Hi Aijun,
>
>
>
> Les kindly points out that what I’ve suggested here is completely
> non-standard and requires multiple IS-IS instances.
>
>
>
> Tony
>
>
>
>
>
>
>
> On Aug 16, 2019, at 9:03 AM, tony.li@tony.li wrote:
>
>
>
> Hi Aijun,
>
>
>
> If, as you stated,  we connect R1 and R7 via one link(although we will not
> do so, if we design the network hierarchically), how you flood the link
> information hierarchically but let the traffic between the two connected L1
> area bypass the L2 area?
>
>
>
>
>
> The link between R1 and R7 needs to belong to either the top area or the
> bottom area.  R1 or R7 needs to participate in two areas and leak routes
> between the two areas.
>
>
>
> Tony
>
>
>
>
>