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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Mon, 26 August 2019 19:29 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 A376B120D4C for <lsr@ietfa.amsl.com>; Mon, 26 Aug 2019 12:29:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.4
X-Spam-Level:
X-Spam-Status: No, score=-14.4 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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=H1cALmhM; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=xuP4Hblo
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 fvk74qzAlzT2 for <lsr@ietfa.amsl.com>; Mon, 26 Aug 2019 12:29:48 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDB34120CAA for <lsr@ietf.org>; Mon, 26 Aug 2019 12:29:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38992; q=dns/txt; s=iport; t=1566847787; x=1568057387; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=iOJ/mwj2V7ofkk2dPWyNc/Ki4bH7VY/Xgs9CGk6St7Y=; b=H1cALmhMWYi8ggEOEC9IWEaJMoFU78m5iGSneY1q41QuxjOmUoGnzCUv OpjjPt7gSmN6NKVayHqXYA2YZFpUu5HYCzUgj5OyewR/sZlnbXCZUHWKy QHMhA8Yrvtc0PuftLxBbm5r4RqcrNX5Iv4tWiVLammQJVtLw/1cgfrjdm E=;
IronPort-PHdr: =?us-ascii?q?9a23=3A5J+DyR0nvl0zHootsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQBkz9N/TndSMSF8VZX1gj9Ha+YgBY?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAAD3MmRd/5tdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVgEBAQEBAQsBgRUvUANtViAECyqEIYFfgWgDim+CXJd?= =?us-ascii?q?oglIDVAkBAQEMAQEiCwIBAYEFXYJdAheCUCM3Bg4CCgEBBAEBAQIBBgRthS0?= =?us-ascii?q?MhUoBAQEBAxILBgoTAQE3AQ8CAQYCEQQBASEDBAMCAgIwFAkIAgQBDQUIGoJ?= =?us-ascii?q?7BAKBHU0DHQECDI4zkGECgTiIYXOBMoJ7AQEFhQQDFYIWAwaBNAGLcRiBQD+?= =?us-ascii?q?BEAFGgU5QLj6CYQEBAgEXgUkVDwcJglUygiaMMiAkgieFE4kIjjYJAoIehmq?= =?us-ascii?q?FAYhzgjKHMItpgwSNaIdrjgOCOAIEAgQFAg4BAQWBZiINgUtwFYMnE4ILJAk?= =?us-ascii?q?DFxWDOoNGgU6FP3IBAQEBgSWNOG8BAQ?=
X-IronPort-AV: E=Sophos;i="5.64,433,1559520000"; d="scan'208,217";a="319616894"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Aug 2019 19:29:43 +0000
Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x7QJTgKk010425 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 26 Aug 2019 19:29:42 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 26 Aug 2019 14:29:41 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 26 Aug 2019 14:29:41 -0500
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 26 Aug 2019 14:29:41 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i6wO3c9oimuldVkS6nIkLJ6daTButpZoib57np60g63dXp6plt3PoNloOJlUQRyAkANFnQ86qzFxarYTRja70patPYZ+EHXvMDWVRzzcPnot+CZpRd9Ru7c0SyHlMYmtkRXBmHk5OprjgaF5eLDV5JDSFGmU7ixQiCAPeiSu18X+zlOOuXO9W6TXmn7vVvC+7VcVuIZ5xXfPJklKXHobKp4hMWnxmHTfP/00x5dVtWIQN340hvhZFwdKczC7JQHFH9dncEIePH4kxSPWmjr6Sol7LHCKOUxrrLoI5KHJGkGCtB160TrfwfDzSBJKiZtPyH2oG74A6sQIHHJkwRIdng==
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=iOJ/mwj2V7ofkk2dPWyNc/Ki4bH7VY/Xgs9CGk6St7Y=; b=aWVmQ4QiFmaxU96HAwFv/3m3SYNFHgZNUVsXlWpgMIE0y2NGgrDjjsyRG5Pqh/9wDklzZ4bEM1GLxRjkcUSVwd4RLrAgrnGa4p3jK2PQvfPXBxzbuL7WJg3HhNTQwUEJ7yF77aexEh6XEwmuP9ftDBPLSfrogldMx6HZ1vKqGW7GmARCX6fN1SN+ekYU48jg1kXqUZF+mdm13KDWkb7BRYS6nwMb1RftOotj2WcabWQl0A9LR+Yhx9TnhvC4IYnt7RnJt6K7FsJWaCk3HMHob8jE+n2Cbr3AfY4U+k0mCT9XMzFQVta4J0lMTnBqVmIA8XIuD0LWa0RUA+0MkSRlvQ==
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=iOJ/mwj2V7ofkk2dPWyNc/Ki4bH7VY/Xgs9CGk6St7Y=; b=xuP4HbloTFvn9xXsUDHUWCafTWElTrLInfOBEMsxaS1ZOPjc21DxeR7QMbCBZg98DpNnc0CSdvp9IAO1MuSlUErZHOHIdJMEpPRCwnFH+Ic2EILtamUUEZtMrUvddwuSkTXb4pK+e3hXHrPheSEvkjg2YXqJdpvYzdI/kebjrL8=
Received: from BYAPR11MB3638.namprd11.prod.outlook.com (20.178.237.19) by BYAPR11MB3176.namprd11.prod.outlook.com (20.177.127.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.20; Mon, 26 Aug 2019 19:29:39 +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.2178.023; Mon, 26 Aug 2019 19:29:39 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Huaimo Chen <huaimo.chen@futurewei.com>, "tony.li@tony.li" <tony.li@tony.li>
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+fcAdO3zAqcCjoCAgAAXPACAAOMhQIAKTbiggAAOEjA=
Date: Mon, 26 Aug 2019 19:29:39 +0000
Message-ID: <BYAPR11MB3638CB8BD8915A51734B94ADC1A10@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> <BYAPR11MB3638231162215DC49170C65FC1AB0@BYAPR11MB3638.namprd11.prod.outlook.com> <MN2PR13MB34702DEEB19FD8D7A66445FCF2A10@MN2PR13MB3470.namprd13.prod.outlook.com>
In-Reply-To: <MN2PR13MB34702DEEB19FD8D7A66445FCF2A10@MN2PR13MB3470.namprd13.prod.outlook.com>
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::700]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6ed66a98-7dbe-4c59-310a-08d72a5bbcc1
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB3176;
x-ms-traffictypediagnostic: BYAPR11MB3176:
x-ms-exchange-purlcount: 3
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BYAPR11MB3176369F2321DA7E12ED63B2C1A10@BYAPR11MB3176.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01415BB535
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(346002)(376002)(39860400002)(396003)(199004)(189003)(42274003)(486006)(478600001)(11346002)(476003)(186003)(46003)(790700001)(6116002)(966005)(446003)(53546011)(6506007)(102836004)(99286004)(7696005)(76176011)(4326008)(71190400001)(71200400001)(110136005)(316002)(6246003)(54906003)(107886003)(25786009)(33656002)(52536014)(2906002)(5660300002)(256004)(14444005)(53936002)(236005)(9686003)(55016002)(6306002)(54896002)(66556008)(76116006)(66946007)(66446008)(64756008)(66476007)(229853002)(86362001)(606006)(6436002)(8936002)(81166006)(81156014)(8676002)(7736002)(74316002)(2501003)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3176; 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: AhvOV0IN1BvUAyHHE0ZEi7jEBMWF1T6wJpsCBleJWROLlL+C6NheOi5sOrqOicbxZwzGptmnEU2EPfokuTNKnEKQCFJue9MO4cqugGNIVyp8NJcase7SFraypnF9fPe4QZu2q6UC0bSLZ7c3xhohrRrsce2g3ibqufWhiPYmA1lphICqJFU+8yalqjAJTwGmtPyGOfMnqIyqdbe0dhL1j+Is5rWc5trWn+2w/IPHJv/kJ6iIzPyPz25Oh3idm8rhgt35x78SBv1ThKcQ+H9c1fesBRaEiJqh2k5kg4ekbwi/NYeLKuUbYgLyI09QeDbyDAS4s6k2iam8Ghd+i2HeHAa3rBq3Covck1Cy53P2i/u1qvlea1CVE+v7BE1x/JknHRmCEAJhTpdQNd+OZ9IAQwIb5TbA0UyU/c8opgPZqGw=
Content-Type: multipart/alternative; boundary="_000_BYAPR11MB3638CB8BD8915A51734B94ADC1A10BYAPR11MB3638namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6ed66a98-7dbe-4c59-310a-08d72a5bbcc1
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2019 19:29:39.1773 (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: uzhxEZ2LtXTa6s0xP1JYC3syGjie5mkRIBwQctpsQhz9/DLCRsXDL16nGgZcN7Gy03xa5teqnaRU0yIbpbSyYA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3176
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.27, xch-rcd-017.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/WBOs1sem874ydOzpjyTK6P81X5U>
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, 26 Aug 2019 19:29:52 -0000

Huaimo –

In regards to:

<snip>
[Les:] Please see https://tools.ietf.org/html/draft-li-lsr-isis-hierarchical-isis-01#section-5<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-li-lsr-isis-hierarchical-isis-01%23section-5&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cfb1a92e407244a396c9908d7252e178c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637018752215524711&sdata=jp8E5Ej4OhjEAO20r0RQuRQJ84J0zeNkbWEcgbdU6Yo%3D&reserved=0> . 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.

[HC] This is one option, which seems dependent on RFC 7356. If RFC 7356 is not implemented by a vendor, it may take more time and efforts for the vendor to implement the isis-hierarchy. The alternative above (i.e., using new PDU Types for level n LSP/CSNP/PSNP) seems simpler. It may be easier for a vendor to implement it since it does not depend on RFC 7356.
<end snip>

This is a point I feel quite strongly about.
RFC 7356 addresses a number of protocol limitations – which include:

a)Carrying capacity of an LSP set – expanding that from 256 LSPs to 65536 LSPs
b)TLV length limitation of 255 bytes

Both of these limitations are applicable to all levels – including the new ones introduced by draft-li-lsr-isis-hierarchical-isis.
I do not want to define extensions to the hierarchy and then have to revisit that and find a way to address the above limitations in some future draft.

Given that we need to introduce new PDUs, the extensions are NOT backwards compatible. Therefore requiring folks to implement RFC 7356 in order to support extended hierarchy does not make the task any more difficult.

   Les


From: Huaimo Chen <huaimo.chen@futurewei.com>
Sent: Monday, August 26, 2019 12:18 PM
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>om>; tony.li@tony.li
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 Les,

Thank you for your response.
Some of my explanations are inline below with prefix [HC].

Best Regards,
Huaimo
From: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>
Sent: Tuesday, August 20, 2019 1:20 AM
To: tony.li@tony.li<mailto:tony.li@tony.li>; Huaimo Chen <huaimo.chen@futurewei.com<mailto:huaimo.chen@futurewei.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>>
Subject: RE: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

Huaimo –

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

From: Lsr <lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org>> On Behalf Of tony.li@tony.li<mailto:tony.li@tony.li>
Sent: Monday, August 19, 2019 8:37 AM
To: Huaimo Chen <huaimo.chen@futurewei.com<mailto:huaimo.chen@futurewei.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Acee Lindem (acee) <acee@cisco.com<mailto: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.

[HC] It seems that the chance for someone to use level 5 to 8 is very low. It may take lots of time and efforts for someone to plan splitting existing areas into more areas with minimum service interruption. It may take even more time and efforts for someone to plan splitting existing levels into more levels.
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.

[HC] It seems better to keep the first two bits as its current R (Reserved). Every bit in the header is a rare resource.

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<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-li-lsr-isis-hierarchical-isis-01%23section-5&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cfb1a92e407244a396c9908d7252e178c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637018752215524711&sdata=jp8E5Ej4OhjEAO20r0RQuRQJ84J0zeNkbWEcgbdU6Yo%3D&reserved=0> . 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.

[HC] This is one option, which seems dependent on RFC 7356. If RFC 7356 is not implemented by a vendor, it may take more time and efforts for the vendor to implement the isis-hierarchy. The alternative above (i.e., using new PDU Types for level n LSP/CSNP/PSNP) seems simpler. It may be easier for a vendor to implement it since it does not depend on RFC 7356.


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