Re: [Lsr] Is it necessary to expand the IS-IS level to 8?

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Mon, 06 January 2020 16:27 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 4F20A1208FC for <lsr@ietfa.amsl.com>; Mon, 6 Jan 2020 08:27:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level:
X-Spam-Status: No, score=-14.519 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=AYUbmjqW; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=WWlpqite
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 d3UeSQwz9ufI for <lsr@ietfa.amsl.com>; Mon, 6 Jan 2020 08:27:12 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB2C61208F6 for <lsr@ietf.org>; Mon, 6 Jan 2020 08:27:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33614; q=dns/txt; s=iport; t=1578328031; x=1579537631; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=9xOmhGvSnUPsgSsCbY949vvGT8l1XSI69RZ3kZw5/E4=; b=AYUbmjqWzPXyhEkFdxS2YzcqzMFTXacqZWPLnx+ejUjT+9jWYp8JVFF7 RGhBCyE0H+PjyvKusGAOydAZSgXLNyOWll2y+6yUe5qdVg3aB4a15raBS GUjTpdP6wiKmUmkN7FVxYx7JqOyoy3LI4nlx7pUOIRj4YcQKzCQn9i2aX 8=;
IronPort-PHdr: 9a23:bg8HRBUyqFXliYLpm728lkXZegnV8LGuZFwc94YnhrRSc6+q45XlOgnF6O5wiEPSA9yJ8OpK3uzRta2oGXcN55qMqjgjSNRNTFdE7KdehAk8GIiAAEz/IuTtank1HcJZXlJ/8FmwMFNeH4D1YFiB6nA=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C7CgCzXhNe/5RdJa1mHAEBAQEBBwEBEQEEBAEBgXyBJS8kLAVsWCAECyqECYNGA4sBToIRmA2CUgNUCQEBAQwBASMKAgEBhEACF4FSJDgTAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQECARIRChMBATgECwIBBgIRBAEBIQcDAgICMBQJCAEBBAESCBqDAYF5TQMOIAECDAORXJBkAoE4iGF1gTKCfgEBBYE1AQMCg0cYggwDBoE2jBkagUE/gRBIgh4uPoJkAQECAYFiFQ8HCYJaMoIsjS6DEIVXiWOPJQqCNoc0iWWCPIJggkYwh02EQYtXjlOIU5IGAgQCBAUCDgEBBYFpIoFYcBWDJ1AYDY0Sg3OFFIU/dAGBJ40/AQE
X-IronPort-AV: E=Sophos;i="5.69,403,1571702400"; d="scan'208,217";a="698016334"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Jan 2020 16:27:10 +0000
Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 006GRAne026216 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 6 Jan 2020 16:27:10 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 6 Jan 2020 10:27:09 -0600
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 6 Jan 2020 10:27:09 -0600
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 6 Jan 2020 11:27:09 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ktJmSCsCWBduxQNDIKBkzareQ0RHNfX9L9Fl1JgQLTzVHtXGdoqotV4xXgOKJR/0m8u9ftFet2TiLxaLempCUbl9jnCC1k5AyQKShaMW6/2xwV4FksW+t9nhuO/7/E+h5x25pc4cme2QlAuQ7rYX7FIE2j1BTb3XetQ6C6NgGflybGF3naA3t+TTzpErY6wYZepNDdpL8hjdaFiC2TG9pxeK6t6rG+PQ8yyh5IS29JXOCwiweAyzh3l6IUMJOaPnZ32Bq5aF8Re1LmhsFuPo092dNDVG96ScFICxoYQitkpEOg5997gG3lmbX5nkvhBSronpwv/XAgcRbXFN33YTJA==
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=9xOmhGvSnUPsgSsCbY949vvGT8l1XSI69RZ3kZw5/E4=; b=nmj3CNAxlIChbz6i0bszbsZL8KCcRByEMzVT9KzJagk9WwmhqZNY96m+VYEfW2Gfv+qLTSxlF/9rX0nZbMfkiBD2gF1pBKMgx0zeEU3ryMEpLZKJbvjLgLNJbA/SDdM/mCDVMNgxZl+xnJVoQAz3KfdWL1ydPDUYfsXF91DPzTAllzHh3fm22CeKa+ljH7TcUMtAT8V3HlH53Lw7r17Fycv+whN4gBzNwkj7EwvMUh+NJBpL3Rhl6mYim7bACpONSHoUEV5OHbsWlnyIb7XvlkUJhaCOyYHRKBlDm1+Lg5JEvrGSJksWQRh6KqQAMk4ZFtooG4chpsdEHVCFfwIcCA==
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=9xOmhGvSnUPsgSsCbY949vvGT8l1XSI69RZ3kZw5/E4=; b=WWlpqitee9++SXInAAQgIBGsX5V2jWLpl1CkgFK0t4smnSm4kCGAgVV5Oy4wQ8T0o+Il8DhO8fXNjKJezr/CncMyBve5eIUBBXDyAyxz4+yBruRUdxutQPuwNvfHwlLAbI+imwgK5IuMLCuwy2knjRGwYVTCYfpnD6VyTVvhYEI=
Received: from DM6PR11MB2842.namprd11.prod.outlook.com (20.176.98.140) by DM6PR11MB3979.namprd11.prod.outlook.com (20.176.126.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.13; Mon, 6 Jan 2020 16:27:08 +0000
Received: from DM6PR11MB2842.namprd11.prod.outlook.com ([fe80::f888:dab1:b205:ed9c]) by DM6PR11MB2842.namprd11.prod.outlook.com ([fe80::f888:dab1:b205:ed9c%7]) with mapi id 15.20.2602.015; Mon, 6 Jan 2020 16:27:08 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Aijun Wang <wangaijun@tsinghua.org.cn>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] Is it necessary to expand the IS-IS level to 8?
Thread-Index: AdXERihUo/c8ffymSLyjWA20ox97mQABh7ywAAUJwzAAEy04QA==
Date: Mon, 06 Jan 2020 16:27:08 +0000
Message-ID: <DM6PR11MB2842F37B76DA9B8B6AF14CDCC13C0@DM6PR11MB2842.namprd11.prod.outlook.com>
References: <010801d5c446$29131950$7b394bf0$@org.cn> <DM6PR11MB28424A0E87EBF51C2AFFD00AC13C0@DM6PR11MB2842.namprd11.prod.outlook.com> <012b01d5c469$310c7d90$932578b0$@org.cn>
In-Reply-To: <012b01d5c469$310c7d90$932578b0$@org.cn>
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:1003::51f]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2c6d16a5-d4c5-4e31-9546-08d792c54673
x-ms-traffictypediagnostic: DM6PR11MB3979:
x-microsoft-antispam-prvs: <DM6PR11MB397936EC66B5995282030DF8C13C0@DM6PR11MB3979.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0274272F87
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(396003)(366004)(346002)(136003)(85664002)(199004)(189003)(33656002)(86362001)(8676002)(71200400001)(110136005)(81156014)(81166006)(2906002)(8936002)(76116006)(316002)(5660300002)(66946007)(66574012)(6506007)(53546011)(64756008)(52536014)(66446008)(7696005)(966005)(55016002)(9686003)(478600001)(66476007)(186003)(66556008); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB3979; H:DM6PR11MB2842.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: BCL:0;
x-microsoft-antispam-message-info: haa/uLHnziH0Nz1rSu/qqK3Z8FSknI7Lf3NZESutX2tqwQ1E0RHNvYnvJg5KU8tGwpUOLNzVaHzx/u/t4r+xl2xyybBcx+ReG8DKvjjyar8sli+cqN/8Cy3uGaDx0sylEhi15wXF0Sw/am0bn+342Z8K+TrKRxM/n/mZVXS0ykE87C49uXjLwx0DHksM+rVn0fhGliVZZWhln3zWvK5GbWEsbuodhongwBTomn6aaVdD69Ozkish5xcphdXYZaltkZt8kkpaQ9vgTDOdKU4fR7WX1uCWQzpLTPmoW/DHopeovRu2dpuEBwNVwPhy2vho0arL6HqhN0EM4Qk5cE60zFcr1UtJZZVmTdZQECog1sFhtUE1ArfFvp6iGiXDDXM3susDZLTzLw7v2w0RXwrv/hWjiITY/BJjH/JXO10nGy24u5LoVDOBISCoTZPLKv+IVPuG9xSRyaPVL9GAiFGNUqczK0+jGK8CZtjbsq6vCfqh1o6ibMyokKAuMD2nWy2npzc2qC9EZdUki995sHuqpxdgQOrVtceO33cXmAeMxbA=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DM6PR11MB2842F37B76DA9B8B6AF14CDCC13C0DM6PR11MB2842namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 2c6d16a5-d4c5-4e31-9546-08d792c54673
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2020 16:27:08.3547 (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: CUoxO6mTnI4PVYKzGOXEduy2Y83VlQMbuH7J6kbcoXVnRzg95se8V4/iE9bJnZKpm+8fVXZCyuCHlwY12Bwq7Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3979
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com
X-Outbound-Node: rcdn-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/rjyJ3wJAE7x0fowpmCfLE2XOw3Q>
Subject: Re: [Lsr] Is it necessary to expand the IS-IS level to 8?
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, 06 Jan 2020 16:27:14 -0000

Aijun –

Hmmm…let me see if I understand you.

You and some other folks have an as yet unpublished idea to use some of the bits in circuit type field and therefore you are not happy that the hierarchy draft will use all of the circuit-type bits for levels.
Is this correct??

It is hard to comment on an unpublished idea – but I would point out that the field being used for levels is a field in the header of PDUs – and new PDUs at that. It is therefore hard to see how this is relevant to information about a particular interface which is always contained in a TLV – not in the PDU header.

If you are talking specifically about IIH PDUs, note that IIHs are never sent on passive interfaces.

But it is hard to comment on an idea that you have yet to publish.

   Les


From: Aijun Wang <wangaijun@tsinghua.org.cn>
Sent: Monday, January 06, 2020 12:14 AM
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; lsr@ietf.org
Subject: 答复: [Lsr] Is it necessary to expand the IS-IS level to 8?

Hi, Les:

We just want to distinguish the passive interfaces from other normal interfaces within ISIS domain.  It seems that the “Attribute Flags” that described in https://tools.ietf.org/html/rfc7794#section-2.1 is the most appropriate place to extend to carry such information.
If so, we can write one draft to define one more attribute flag to accomplish this.

Or, is there any other way to fulfill this task? Originally, I want to reuse the reserve bits before “Circuit Type” field.  It seems not the right direction.

And on the other hand, occupying all the reserved bits for the unnecessary expansion is also not the right direction?

Best Regards.

Aijun Wang
China Telecom

发件人: lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org> [mailto:lsr-bounces@ietf.org] 代表 Les Ginsberg (ginsberg)
发送时间: 2020年1月6日 12:52
收件人: Aijun Wang; lsr@ietf.org<mailto:lsr@ietf.org>
主题: Re: [Lsr] Is it necessary to expand the IS-IS level to 8?

Aijun –

Regarding the number of levels, Tony responded to a similar comment several months ago – please see https://mailarchive.ietf.org/arch/msg/lsr/dKJBcU59TNuY3rxgjd6iXIq6sYg

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

<end snip>

Link type in OSPF is not at all the same thing as level in IS-IS – so I do not find that analogy appropriate:

From https://tools.ietf.org/html/rfc2328 page 128

<snip>
Link type   Description       Link ID
                   __________________________________________________
                   1           Point-to-point    Neighbor Router ID
                               link
                   2           Link to transit   Interface address of
                               network           Designated Router
                   3           Link to stub      IP network number
                               network
                   4           Virtual link      Neighbor Router ID


                           Table 18: Link descriptions in the
                                      router-LSA.
<end snip>

   Les


From: Lsr <lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org>> On Behalf Of Aijun Wang
Sent: Sunday, January 05, 2020 8:03 PM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: [Lsr] Is it necessary to expand the IS-IS level to 8?

Hi, Tony, Les and Paul:

As I read the draft https://tools.ietf.org/html/draft-ietf-lsr-isis-extended-hierarchy-00, and notice the proposal to expand the reserved bits in “Circuit Type” to cover the level 1-8 in ISIS domain.
Here I just want to know is it necessary to expand the IS-IS level to 8 and occupy all the reserved bits in the PDU format?

As compared with the OSPF format, there is one field to describe the “Link Type” (5 bits, currently define only four types). We want to use the reserved bits in current “Circuit Type” of ISIS PDU format to fulfill the similar tasks.

Can this draft leave at least 2 reserved bits for this purpose? There are many ways to tackle the scale of networks, who will design their network in level 8 hierarchy? As I estimated, Level 4 may be the acceptable highest network hierarchy.


Best Regards.

Aijun Wang
China Telecom