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

tony.li@tony.li Mon, 19 August 2019 15:37 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 D7F6B12011B for <lsr@ietfa.amsl.com>; Mon, 19 Aug 2019 08:37:18 -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 s5ZyRbptTsf0 for <lsr@ietfa.amsl.com>; Mon, 19 Aug 2019 08:37:17 -0700 (PDT)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 4DA60120106 for <lsr@ietf.org>; Mon, 19 Aug 2019 08:37:17 -0700 (PDT)
Received: by mail-pg1-x52f.google.com with SMTP id n190so1442424pgn.0 for <lsr@ietf.org>; Mon, 19 Aug 2019 08:37:17 -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=Cc55oOK0BUv20deirvMBOq88MRGPjV4Ewix9RowMsfg=; b=gWjTsN96QCYa2ZAUjTBTpXu4sVN7YNVXVPOupzlCht8D1CJeihKzlUrUuf4j0ZMmY9 jFY3xxE0Q/ghPh7dgoMhSKenyKXQVe77bU995wbSzQ9X6Q9BAtzRHcsLfKRJPP3Aduzk YBuuMtcgADIaxvfEyVgwgB/s16rIH+i/tSGculaEgloB+I6q89IW+9oi+wES9XmAEYsF nK3aHYixrGaPiDOWyv8nrq+3S1CZj3/HO6QY+KMW+0jhgr7bLHMMY2N9X2r+aAdfANMk uNC+DL+kxHz8odmYENdr7v9D7RUeIUdZtbYjhTQQ4WPhT18hQ64zXX9wCMoxSIkOWPfW oMag==
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=Cc55oOK0BUv20deirvMBOq88MRGPjV4Ewix9RowMsfg=; b=dXiE/AwxHPK3YDFkuFqGnpQX201o7VfMPPr2UHaUCJS3NJpQMXEG62Qo/Po35c+UX6 54lnz7dO4xnfv//eh5jgPJ/jTKQroxsYanNfCgY5cON8r9aivWsROl8YIICuTtCO9biV gRyeTa5Fnx7oARYbWmfbOBGqksyHOoVe15+QDgv2YZ4kJ5bjSN6CFQlIz3Iz09BxcLAu DLvub3/8SWID2Kr5KQfKIZ5fcZEs3vCN8ZxVwLZs2LNsGMPg289IMBpAVNeay1CBFMa2 apOH7RPkL7Giy+CZcrUxACfylJpr0ZOpLUPJ8MAdUio8in7aS0t4NOvVFBVtMDRvyVCE 21cQ==
X-Gm-Message-State: APjAAAWv2rNKfyMpbis9R+3vg1CQXeXzmM0gSjM1gZcTHCb9FefsXV+j i1PbkfKMTYTrzJq2FUcKSNI=
X-Google-Smtp-Source: APXvYqzmMVuTLiMsE0Lbg7+sPsKwFtwEtGEe3/ZO2A4wJytFmXk/zKuNpVBTgmvOHF2EtN2AFQwHBw==
X-Received: by 2002:aa7:988a:: with SMTP id r10mr23722121pfl.253.1566229036795; Mon, 19 Aug 2019 08:37:16 -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 dw7sm13779265pjb.21.2019.08.19.08.37.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Aug 2019 08:37:16 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
From: tony.li@tony.li
Message-Id: <9713B674-9E80-4B86-9CE4-738155367CF7@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0F74C712-FD8C-4758-BF90-760D8C588B24"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 19 Aug 2019 08:37:14 -0700
In-Reply-To: <BY5PR13MB3459D8CA48EBF7B98B1ED37EF2A80@BY5PR13MB3459.namprd13.prod.outlook.com>
Cc: "Acee Lindem (acee)" <acee@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
To: Huaimo Chen <huaimo.chen@futurewei.com>
References: <8BAFFDB4-62B0-4018-966E-6861D89D0BD1@cisco.com> <BY5PR13MB3459D8CA48EBF7B98B1ED37EF2A80@BY5PR13MB3459.namprd13.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/dKJBcU59TNuY3rxgjd6iXIq6sYg>
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: Mon, 19 Aug 2019 15:37:19 -0000

Hi Huaimo,


> Support and have the following comments:


Thank you for your support and comments.

> It seems not necessary to have 8 levels of hierarchies. 3 or at most 4 levels of hierarchies should be enough. IS-IS with 3 levels of hierarchies may support a network with 1k*1k*1k nodes, which is about 10^9 = 1 billion nodes. IS-IS with 4 levels of hierarchies may support a network with 1k*1k*1k*1k nodes, which is about 10^12 = 1 trillion nodes.


This is correct.  It’s not absolutely necessary. However, as Robert mentioned, it does give the network designer flexibility to create the hierarchy that matches the needs of his network.  The cost of the additional levels is very small, given that we’re considering adding any levels at all, so it seemed sensible to define all of the levels at once.

“From an architectural point of view, if a number isn’t obviously too large, then it’s probably too small.”  — Ross Callon


> For PDU type, section 2.2 of the draft proposes to use 8 bits (all three reserved bits plus the 5 bits for the existing PDU type). It seems better to use 6 bits (one reserved bit plus the 5 bits for the existing PDU type). Adding one reserved bit into the PDU Type allows people to define 32 new PDU types, which is enough for the new PDU types needed for new hierarchies.


Agreed, it’s more than necessary.  Since we’re opening the issue, it seemed useful to make use of the space.

> Section 3 “Additional PDUs” of the draft, defines 6 new PDU Types for ’Level n LAN IS to IS hello PDU’ (Ln-LAN-HELLO-PDU), where n is 3, 4, 5, 6, 7, and 8. In addition, the following new PDU Types should be defined (considering at most 4 levels of hierarchies):
> 2 new PDU Types for ‘’Level n LSP”, where n is 3, and 4
> 2 new PDU Types for ‘’Level n CSNP”, where n is 3, and 4
> 2 new PDU Types for ‘’Level n PSNP”, where n is 3, and 4


That's a natural consequence of your first point.


> On a broadcast interface, Level 1 LSPs are multicast through MAC 0x0180.c200.0014 (which is called AllL1ISs), and Level 2 LSPs are multicast through MAC 0x0180.c200.0015 (which is called AllL2ISs). It seems that Level n LSPs should be multicast through AllLnISs, where n is 3, and 4 (considering at most 4 levels of hierarchies), thus 2 new MAC should be assigned to AllLnISs, where n is 3, and 4.


Good point, thank you, yes, we overlooked that.


> The existing DIS for a broadcast interface periodically multicast through AllL1ISs and AllL2ISs a Complete SNP (CSNP). It seems that the DIS should be extended to periodically multicast a CSNP through AllLnISs, where n is 1, 2, 3, and 4 (considering at most 4 levels of hierarchies).


Agreed, but we were not planning on being explicit about restating all of the rules for each level.  We should be more explicit and say that all behaviors of level 2 are replicated upwards.


> When there may be 3 or more levels of hierarchies, is it allowed to have 3 or more levels (consecutive) configured on an interface? It seems that there is no description about this in the draft.



This was intentionally not precluded and thus supported.  Again please note that as are only defining the behavior for contiguous levels at this time.

Tony