Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01 Fri, 16 August 2019 19:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3D1C212081B for <>; Fri, 16 Aug 2019 12:42:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Status: No, score=-1.401 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5JJPCc6JWIRQ for <>; Fri, 16 Aug 2019 12:42:53 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A2E8F12081A for <>; Fri, 16 Aug 2019 12:42:53 -0700 (PDT)
Received: by with SMTP id go14so2542772plb.0 for <>; Fri, 16 Aug 2019 12:42:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BVV3hiFzFoSBhenDY1bKWzW3p/WJVRYdD8LDS0Vlgb8=; b=urHuYchoEPeJ5CT/btw/vunJHOpaAwxgs4dxDJEau0QAKIuZAGafvAvuSVCly4KQSr ZMmUVthp2zfF1WEpSpmF+pxD217hFD0SfDegsG3jqOIMMq+yi3YIJY/7uulJCnxK2gXW vacCOVNWPyA2obJA/72uKhgvm8+9NO9D+Rfg1wZQ8/22xM4qvWyLlKv4neuRag8MDAcL HEPclTMJjO6ue3+Zw2atjp0dXHQnEfELpA/7kV6z4FYC3d2OYke6aZiAL23KPwa7vlLd G4nvBbMWDwBuospMbrP2O9hSYQCJyQIqegXm2txZGD1ewJvIunqci0UndFst6VQPuh6l U+ug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=BVV3hiFzFoSBhenDY1bKWzW3p/WJVRYdD8LDS0Vlgb8=; b=GOdamrbWCIm9hNSqzoyyEox+kSW0pLhI18LaFaQTAEyFGeORNenEtV7VlnRdtmjuQv clDlRlGSPxWPtQCQeNfogrLfrHHY/E2rjBQQGnx1xCoyPszrUxJSFJTsn0P1rKZpMn6e HbMmkwgscJ7Pg2N6vCJfsz8TIE3oVFa/gx0DoYjQdHUH2eeS3kg81xRjMnRPtxH/ZIMQ tkVYlrfMyNFGa7wQXyydpUtAB4h2/0U8Xtt3xgvfQGxN538iz5f5KXUmUh1W6noZLgbA dnu3a8Ln9iDsFRC0EriHA/2niN7ArM/TnCdpuk6Mz1vGcvmIYYbgdtR9M/aTnsuf12tJ uk4g==
X-Gm-Message-State: APjAAAUoia7wheSb45nVC2KHyOnyPKMAOiZ3SeMBH/y1AMxgIW4gjS0Z 1zTLZCtnKvEeJ8TcpgkwY+w=
X-Google-Smtp-Source: APXvYqy3/ECCpTGFnZaAa1p5E86R1yGnbRDRMUOszehH3pp/9I5ihykUviQ7ue3RaWz0k5M4hYEdZQ==
X-Received: by 2002:a17:902:246:: with SMTP id 64mr10017782plc.99.1565984573169; Fri, 16 Aug 2019 12:42:53 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id g2sm13630491pfq.88.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Aug 2019 12:42:49 -0700 (PDT)
Sender: Tony Li <>
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <>
Date: Fri, 16 Aug 2019 12:42:47 -0700
Cc: Les Ginsberg <>, "" <>, Aijun Wang <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <01a501d55338$945c2b40$bd1481c0$> <> <> <> <00b601d553fe$9636a5a0$c2a3f0e0$> <> <> <> <>
To: Robert Raszuk <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-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: Fri, 16 Aug 2019 19:42:55 -0000

Hi Robert,

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

It’s the best answer that we have today.

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

If you have a number of areas all at a single level, you need to have some mechanism for computing paths between the areas.  You suggest ‘LSP reflectors’ which might suggest carrying all LSPs from one area and putting them into another area.  That approach has the same scalability properties as just running one single, giant area. I would not recommend this.  

If I take a less literal interpretation of ‘LSP reflectors’, then you are performing summarization, not reflection, at area boundaries. If no further information about the inter-area topology is known, then this devolves to a distance-vector like approach, where summaries circulate between areas and cumulative metric information is used to select the optimal path.  Effectively, you’re running RIP for your level 2 protocol, with all of the benefits and deficiencies of RIP.

If you would like an incremental improvement, you could carry path information with your summaries, and perform a path vector based path selection.  Effectively, you’re running BGP as your level 2 protocol, with all of the benefits and deficiencies of BGP.

And, of course, if you would like to carry full topology information in level 2, you could have the properties of a link-state protocol at level 2. IMHO, this is optimal at this time.

Now, if someone wants to come along and provide an entirely new concept in routing protocols, they could certainly do so, but we really haven’t made significant progress in this area for 25 years, so waiting would seem to well over everyone’s retirement event horizon.

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

I submit that the question is largely irrelevant to the matter of working group adoption.  We are not obligated to select only the best, if only because that can change over time. Further, we have no other proposals on the table.  Our proposal is the natural and logical extension of the two-level hierarchy that was originally conceived for IS-IS. From the perspective of getting to ‘running code’ it is the obvious choice because almost all of the code written for level 2 can be trivially abstracted for other levels. We have demonstrated significant working group interest already, so we should move forward so that we can enable people to use this tool if they choose to.