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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Tue, 20 August 2019 05:20 UTC

Return-Path: <ginsberg@cisco.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 BADA11200F3 for <lsr@ietfa.amsl.com>; Mon, 19 Aug 2019 22:20:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 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_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=AhFB5sti; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Dng3pjNa
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 z8Up_nJu2xym for <lsr@ietfa.amsl.com>; Mon, 19 Aug 2019 22:20:19 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D52561200C7 for <lsr@ietf.org>; Mon, 19 Aug 2019 22:20:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22732; q=dns/txt; s=iport; t=1566278418; x=1567488018; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jopnLh32F035DWTqgWtmcSThzxRDAo6sxW4jSsL8tbg=; b=AhFB5stiWau4eMhVqc0EOLZTGRI3SvCS+eVoi5FxtvPVAfxlkyzJ1VED aIKIVk8t69MzY4tEYb6wdd9CAxxP2PoKnGk8Z8FfLuosoYP7qBgN8sX/6 lJOf6xZhFAfvrn4RM03rRyFqKM6meG7djAlyx3GEUrLJpjpniAO+xT/OI s=;
IronPort-PHdr: =?us-ascii?q?9a23=3AT2dfch8nSDSqb/9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVcGED1bxIeTlRyc7B89FElRi+iLzPA=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B7AABEgltd/5FdJa1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZ4EWL1ADbVUgBAsqhB+DRwOKe4JckwuEWoJSA1QJAQE?= =?us-ascii?q?BDAEBJQgCAQGEPwIXgw8jOBMCBQEBBAEBAwEGBG2FJwyFSgEBAQEDEgsGChM?= =?us-ascii?q?BATcBDwIBBgIRBAEBJAcCAgIwHQgCBAENBQgagwGBHU0DHQECDI5dkGECgTi?= =?us-ascii?q?IYXOBMoJ6AQEFhRAYghQDBoE0i2kXgUA/gRABRoIeLj6CYQEBAgGBYCQHgl4?= =?us-ascii?q?ygiaMLoJohQ+JAo4wCQKCHYZojWyCMYcwjmONW4dikCoCBAIEBQIOAQEFgWc?= =?us-ascii?q?hgVhwFYMngkIMFxWDOoNGgU6FP3KBKY1QAQE?=
X-IronPort-AV: E=Sophos;i="5.64,407,1559520000"; d="scan'208,217";a="531336767"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Aug 2019 05:20:17 +0000
Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x7K5KHIT023142 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 20 Aug 2019 05:20:17 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 20 Aug 2019 00:20:16 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 20 Aug 2019 00:20:16 -0500
Received: from NAM05-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 20 Aug 2019 00:20:16 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G7OvAPqp4rjXbG0U7r9SSfI0EAWxWhJCHNuuSnyNQtPdWeoSU04gIXpir4HlgPlCWpfqO8m82kUvn3MwbWzO02Sr8+J789srBJj/xnHakltjH4EnfzC5ZcSyj3RyR5X4bqlR+i/zG9C9bMSf8ibzfOCIWqcAgA4LeES/bKfmau0aM88i6Dbe7id1YSynKPFi8t6MBEsNQZgE6OqHhyTJGKAEuuxBhdVwGQ4P/aydyJJhDl3m+rDLxlPM1OYHFk1uUrOfEipLJ5YQBCAmCDFeMf0Vp6Q6ZfTcKcekZrzra81RFVwwqGhY35rVBUNZ/Xb0KjAvua67IBr88GrpMd0omA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jopnLh32F035DWTqgWtmcSThzxRDAo6sxW4jSsL8tbg=; b=HtwECyddtx4KYOKb1MHV0RACciZPFfy8BM2//HXh+7AE2dA5z9c7L4/LgqUN5vMUQQN0UPzbRM+sxmgLWWvylk0EbfkS7ly81Wc71aWfIKglO3m8Ry0LlrC6RKj8lBwLwzA7S7a8ckFcW95mdCm+zteFFlr82qiBPa781fCbx0++fiGQBev3GWOTMvCovy+uzZRovlZQuiBVgg1wud2jgX8E4o4AoHegu8WCOtsGRirtyP8oE5u9zuXmSqw0XAWJsonsAyEkLSxeafURxjN7Lni3DiwX4+CMLmCLopgsZ9oRiU/PWSKlxBxfvTB9JeXcDdqm1gRIlFGvnXq7o//yDA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jopnLh32F035DWTqgWtmcSThzxRDAo6sxW4jSsL8tbg=; b=Dng3pjNageIPLABOPZ6HTwMrnbPPkPlqFS2XKMfBcI+ARn/lgfhfJWHuu68dIGIBBOZrzy2qbWcr+3MIe3roRxFglem1LQ15RYZp48o0dYL1ByW6pndicmo2W3kQnFVxo3BvapsMnfd6x3E5EbqeIL3/iM2WftQhPuN3a75E+Gw=
Received: from BYAPR11MB3638.namprd11.prod.outlook.com (20.178.237.19) by BYAPR11MB2616.namprd11.prod.outlook.com (52.135.227.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.16; Tue, 20 Aug 2019 05:20:14 +0000
Received: from BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::d8d2:7e49:1687:aab2]) by BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::d8d2:7e49:1687:aab2%3]) with mapi id 15.20.2157.024; Tue, 20 Aug 2019 05:20:14 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: "tony.li@tony.li" <tony.li@tony.li>, Huaimo Chen <huaimo.chen@futurewei.com>
CC: "lsr@ietf.org" <lsr@ietf.org>, "Acee Lindem (acee)" <acee@cisco.com>
Thread-Topic: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01
Thread-Index: AQHVURraLOii8Ni+80mn+fcAdO3zAqcCjoCAgAAXPACAAOMhQA==
Date: Tue, 20 Aug 2019 05:20:14 +0000
Message-ID: <BYAPR11MB3638231162215DC49170C65FC1AB0@BYAPR11MB3638.namprd11.prod.outlook.com>
References: <8BAFFDB4-62B0-4018-966E-6861D89D0BD1@cisco.com> <BY5PR13MB3459D8CA48EBF7B98B1ED37EF2A80@BY5PR13MB3459.namprd13.prod.outlook.com> <9713B674-9E80-4B86-9CE4-738155367CF7@tony.li>
In-Reply-To: <9713B674-9E80-4B86-9CE4-738155367CF7@tony.li>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ginsberg@cisco.com;
x-originating-ip: [2001:420:c0c8:1005::bf]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7237e750-970d-458d-2b4d-08d7252e150f
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BYAPR11MB2616;
x-ms-traffictypediagnostic: BYAPR11MB2616:
x-ms-exchange-purlcount: 3
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BYAPR11MB261681F579490C93FBBF0E6BC1AB0@BYAPR11MB2616.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 013568035E
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(346002)(376002)(366004)(136003)(199004)(189003)(42274003)(25786009)(6436002)(54906003)(8936002)(99286004)(76176011)(33656002)(6246003)(4326008)(9686003)(53936002)(606006)(966005)(256004)(14454004)(478600001)(71190400001)(71200400001)(107886003)(186003)(102836004)(486006)(11346002)(46003)(110136005)(446003)(476003)(53546011)(2501003)(229853002)(6506007)(790700001)(316002)(7696005)(6116002)(2906002)(7736002)(76116006)(8676002)(55016002)(66476007)(5660300002)(66946007)(86362001)(52536014)(66446008)(66556008)(64756008)(236005)(81166006)(74316002)(54896002)(81156014)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2616; H:BYAPR11MB3638.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: /0PE0wXNRyGr+wWqXN0oHgrkRUFiARR+x1KgaDUp8WVRSza6wqyrRqv2ttKuuSEZpl8DNhHxQsTc3+nq3U6FZZMRX/JBJmwnumIRPZXqhGVQb4FwseFSd4jmaLLv4pe3tKOfjoTuWYhnVrs9ppHay7JhBIEYXKfoZLkW5aOK+Sn7iRp2LLlrx5vr0NHrsaAxDHQLACLEmjlKrmRVlpUvwGIP7Li5Ov2u0GoKjOgq3JU08vrIN2eko3Xtpx40jEpDYb5K3C/NJOuGPUX4mrV5gs8xsQS/tiUlO3Med0CP1Y7C+ZT9iaTnbCduqVB7ZQr3x2DctbRJgoP6zpovGeHAgsEK+cJhGKkisBxwvpaD/ucLhpR2d2QCrtytud9X1o4R5yw49kYBAInKW2wurBpKoyLNx7RC8Vf3MDJqL+hnm/I=
Content-Type: multipart/alternative; boundary="_000_BYAPR11MB3638231162215DC49170C65FC1AB0BYAPR11MB3638namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7237e750-970d-458d-2b4d-08d7252e150f
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2019 05:20:14.6234 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: NYbVTVeyEL+8+FnaJfo4gDviGmtKjZjw/lEKjn+h3ppUbR77OdP20pV96Xdh/4whQc7Gdfuf2pTsgK4PBd0t5w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2616
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.21, xch-rcd-011.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/ijrYK1otO66wwU3VlSfr7SP9uso>
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: Tue, 20 Aug 2019 05:20:22 -0000

Huaimo –

Thanx for your support.
A few additional comments on top of Tony’s remarks.
Inline.

From: Lsr <lsr-bounces@ietf.org> On Behalf Of tony.li@tony.li
Sent: Monday, August 19, 2019 8:37 AM
To: Huaimo Chen <huaimo.chen@futurewei.com>
Cc: lsr@ietf.org; Acee Lindem (acee) <acee@cisco.com>
Subject: Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01


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


[Les:] I would also add that we do not want to have to do this “again” – which might happen if we did as you suggest and support 4 levels – and then someone comes up w a deployment case for 5 levels.. 8 levels is likely more than is needed – but it is fits nicely into the current PDU format i.e., a number of fields are 8 bits.


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):

  1.

     *   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

[Les:] Please see https://tools.ietf.org/html/draft-li-lsr-isis-hierarchical-isis-01#section-5 . SNPs and LSPs for the additional levels use the FS-LSP/FS-CSNP/FS-PSNP PDUs defined in RFC 7356 – with the new scopes as defined in this draft.

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.
[Les:] Future revisions of the draft will be more explicit about adjacency formation rules – we are still discussing details.

   Les


Tony