Re: [Lsr] Enhancements on flooding topology encoding

Huaimo Chen <hchen@futurewei.com> Wed, 29 May 2019 15:06 UTC

Return-Path: <hchen@futurewei.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 22801120156 for <lsr@ietfa.amsl.com>; Wed, 29 May 2019 08:06:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 gJRsiZDFFfVQ for <lsr@ietfa.amsl.com>; Wed, 29 May 2019 08:05:58 -0700 (PDT)
Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-eopbgr710101.outbound.protection.outlook.com [40.107.71.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3F361201AF for <lsr@ietf.org>; Wed, 29 May 2019 08:05:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zgnBZ4ER0qHxcPNjfpnFvhUGYv3exoBsboVkaYpt0MY=; b=VBEq4YdChXKdmzw5b7q5iFQCAlI/YjAarEAFVAe8gIKRQ8f3ErcDYEViEMm0kpnYsYiss7x7doIhbHpSQC76p2KwQjjrHnVSF5p4kugkTJ6ZrC1Afb6iWvP9e5DIYacEfjahrPEuX8RoxphHseH3NKGMvswBLkeIvd3pqeW6Qjw=
Received: from MN2PR13MB3470.namprd13.prod.outlook.com (10.255.237.83) by MN2PR13MB2734.namprd13.prod.outlook.com (20.178.252.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.10; Wed, 29 May 2019 15:05:55 +0000
Received: from MN2PR13MB3470.namprd13.prod.outlook.com ([fe80::b125:6fc1:69df:68b1]) by MN2PR13MB3470.namprd13.prod.outlook.com ([fe80::b125:6fc1:69df:68b1%7]) with mapi id 15.20.1943.015; Wed, 29 May 2019 15:05:55 +0000
From: Huaimo Chen <hchen@futurewei.com>
To: Tony Li <tony.li@tony.li>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: Enhancements on flooding topology encoding
Thread-Index: AQHVFivB4g4Z5BLS3EmftFBvGA6vDw==
Date: Wed, 29 May 2019 15:05:55 +0000
Message-ID: <MN2PR13MB3470347425388859402DE2CFA31F0@MN2PR13MB3470.namprd13.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=hchen@futurewei.com;
x-originating-ip: [73.114.233.24]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a2c0e051-298a-4a4c-b6c3-08d6e447265c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:MN2PR13MB2734;
x-ms-traffictypediagnostic: MN2PR13MB2734:
x-microsoft-antispam-prvs: <MN2PR13MB2734B8B94BF0B0C03EC450AAA31F0@MN2PR13MB2734.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0052308DC6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39850400004)(396003)(136003)(346002)(376002)(189003)(199004)(6246003)(229853002)(6436002)(71190400001)(71200400001)(52536014)(476003)(53936002)(33656002)(7736002)(486006)(102836004)(66446008)(66556008)(68736007)(55016002)(74316002)(66066001)(25786009)(81156014)(66476007)(66616009)(19627405001)(81166006)(53546011)(76116006)(256004)(66946007)(5024004)(99936001)(64756008)(73956011)(8676002)(8936002)(91956017)(6506007)(2906002)(186003)(6606003)(26005)(7696005)(86362001)(54896002)(2501003)(478600001)(3846002)(5660300002)(14454004)(6116002)(66574012)(99286004)(110136005)(9686003)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR13MB2734; H:MN2PR13MB3470.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: futurewei.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: cBRGblZI/oDEeZu/aMkA79b0nqKmxp27r2Bx3EmtC98AdNEUvwQ5jJp5aQ+zI8t5rZV1E6zjau0D1HzlVaOzAKik2gZqGTGsiWW95qCsUQo80SOGuLacIvzubBnW68r1bvqByvEpA8AtIu6/m468gxfX9smSCe+oWzxAjbj9txGvlSJXzyIgZAbBpdcHmoHDSAMahZuUoDDwzR7tjEBWe7EahDVVRo5FN5zLfTr7tKNvLOICrbikcESh5ODvx8zhg8KWgYrb5fpAKPylGtga5Ftvarg6YlvFvyo4A3y4gRjHFJvDiDGZBzw5vhsZfHiqVDc2kTxLMGs0CO5KK3yAaDB6U2ALjBU6e1e9hrDNIkDkSNyBq+sPregQkXLuByxO9tl3/OG3dlHBviB55wt6bDrYNtJW+nlqS9vGH0CNfb0=
Content-Type: multipart/mixed; boundary="_004_MN2PR13MB3470347425388859402DE2CFA31F0MN2PR13MB3470namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a2c0e051-298a-4a4c-b6c3-08d6e447265c
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 May 2019 15:05:55.6155 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: hchen@futurewei.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB2734
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/PLoKxySUV1l5U8Z-TbonoEaXfZ8>
Subject: Re: [Lsr] Enhancements on flooding topology encoding
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: Wed, 29 May 2019 15:06:02 -0000

Hi Tony,

    For the three encodings below,

  *   Encoding A: Plain Path TLVs, where each node index uses 2 bytes,
  *   Encoding B: Compact Path TLVs, where each of node indexes in Path TLVs has the same size given by a field in the Area Node IDs TLV with L set to one, which is the size (in bits) of the maximum node index value,
  *   Encoding C:  Block TLVs,
it seems that C is more efficient than A and B in general, B is more efficient than A.
For example, for representing 63 nodes flooding topology (FT for short) of a binary tree in IS-IS, some comparisons among three encodings are listed in the table below (In case that the formats may be messed up, a .pdf file is attached).

Encoding
Bytes used
Comparisons
A (Plain Path TLVs)
248
179/248 = 0.72 (72%)
B (Compact Path TLVs)
179
121/179 = 0.68 (68%)
C (Block TLVs)
121
121/248 = 0.49 (49%)

    From the table, we can see that 248, 179 and 121 bytes are used for representing the FT by A, B and C respectively. 121/248 = 0.49 (49%) means that C uses about 49% of the flooding resource that A uses. 121/179 = 0.68 (68%) means that C uses about 68% of the flooding resource that B uses. 179/248=0.72 (72%) means that B uses about 72% of the flooding resource that A uses.

    From this example, we can see that C is more efficient than A and B, and B is more efficient than A.

Best Regards,
Huaimo
From: Tony Li [mailto:tony1athome@gmail.com] On Behalf Of tony.li@tony.li
Sent: Wednesday, May 15, 2019 11:55 AM
To: Huaimo Chen <huaimo.chen@huawei.com>
Cc: lsr@ietf.org
Subject: Re: Enhancements on flooding topology encoding


Hi Huaimo,


In one way, a TLV called Node Index Size TLV is defined. Its value field of one octet contains an index size (i.e., a number of bits). When this TLV is included in an LSP/LSA containing Path TLVs, all the node indexes in the Path TLVs are represented using the number of bits given by the index size in the Node Index Size TLV. The index size is the minimum number of bits needed to represent the maximum node index in the Path TLVs.


Yes, Tony P. also made this suggestion quite some time ago in a private communication.  We also observed that no separate signaling of the size is actually needed, as each node can look at the number of indices listed in the Node Id TLV and take ceil(log2(# nodes)) and use that many bits for each index.

In another way, 5 bits of the Reserved field in the IS-IS Area System IDs TLV and OSPF Area Node IDs TLV with L set to one indicates the index size that is used for all the node indexes in all the Path TLVs included in every LSP/LSA. The index size is the minimum number of bits needed to represent the maximum node index in the area.


Yes, you could do that too.  That’s for ‘free’, assuming that you agree that the L bit is required.



In another encoding, Block TLVs are used to encode the flooding topology. A Block TLV represents a block of the flooding topology.  The value field of a Block TLV starts with 5 bits to indicate the index size, which is followed by the index of a local node, the number of adjacent nodes (in 3 bits), and the indexes of the adjacent/remote nodes of the local node. This part is similar to the one in a router LSA to represent the part of the topology from the local node to the adjacent nodes of the local node, which can be considered as a block of the topology in one level. This block can be extended to multiple levels. Each of the adjacent nodes has an extension flag bit E.  An adjacent/remote node with E = 1 is considered as a new local node, and its adjacent nodes are added. This encoding seems more efficient.


A bold claim.  Do you have any proof for this?  It seems counter-intuitive, as for a bi-connected node, it would seem that its index must appear at least twice, once per link.

The advantage of the path encoding is that for almost all nodes, an index can appear a single time.

Example:

IS-IS Instance: Amun VRF: default
  Level 1:
    Path: 3 16 8
    Path: 0 18 9 10 11 17 15 6
    Path: 0 13 1 19 5 4 14 8
    Path: 0 3 6 7 2 8 12 0

Tony