Re: [Lsr] Enhancements on flooding topology encoding

tony.li@tony.li Wed, 15 May 2019 15:55 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 289C412012C for <lsr@ietfa.amsl.com>; Wed, 15 May 2019 08:55:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 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.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 JHxBsrPLm04E for <lsr@ietfa.amsl.com>; Wed, 15 May 2019 08:55:06 -0700 (PDT)
Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 D038C12013D for <lsr@ietf.org>; Wed, 15 May 2019 08:55:06 -0700 (PDT)
Received: by mail-pf1-x434.google.com with SMTP id c6so178858pfa.10 for <lsr@ietf.org>; Wed, 15 May 2019 08:55:06 -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=Np3yc0fSvFqvFSiksDgHwLDE1XvWdPJY3IRwRW10pms=; b=BY2/pNChn2ckcKb7L3svznFM0VidlxrFHTwJpZRhPVqpbD+Nb4jyofzIne1QZtIiCG S/IChB665dJBj3KlK5WVvIctOilNKdpdMhIM/+6xiFZVeeqGRwqspj/e1/fcKMpAfs+/ 1IvVqLh9O3EW0Ui8ojqBWvcwJTm+Jv5iDzd6L3HdqGIih025In/p/VzWzoj8cYsCYvSX QxYzE7NQcHmVgoLlI4owBzOekD7gsppN1GQchoV9+m2t1XaoRvJV9JLYC5Fl17kqJp/j mxKsgeqJLTQtChUTP3iotysBLzi4uVjWsL3QEhnH2vw3tnfy3iBd9lVmOt7wLKBXCV5H bHpg==
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=Np3yc0fSvFqvFSiksDgHwLDE1XvWdPJY3IRwRW10pms=; b=MiziNq2fYk/glDBEvGbmV8l+vgTekb7/uQOVSIYSmUJWVPHd155MTfzBW8bkA9wYmB y9yHNkih0hqaj0U2LjsujekrUFSLrbF/G9P44UAjmGYI97FPU7hvtuopUQIzjlzPxMp+ Qtm3aYlsfWTdv1b0yVpoQZufUbj2c4lIA7dRF8XoQBMKsxVohJKhqzMFZU6e8J2nlSow 4WiWJTn4TV/e/EuYkviqSDTHfDELq2UDYyzBfZ6iWcHQ1if0JUhlgJO5iIxD1MitRZT1 0gfy22Th9bqW6g8JED6k870T7qHpe+Cjty5cuC3jmX31w7qAvt3/gmMiOL0F5X7ZMAaG QZMA==
X-Gm-Message-State: APjAAAXqb2UZvpyr7djVyfvCaodWuEVSz0XPKl3lSEJKHWwH2GlV89nh zm+5MuEXHSiajR6jJLaU2Lo=
X-Google-Smtp-Source: APXvYqyW42rcrDN65XNObHF/yGvgDiqLJmxvYhUkfokHGUACcDTHOFmQWSUYEhcW9oIfKYAbBXIC9w==
X-Received: by 2002:aa7:82cd:: with SMTP id f13mr46938227pfn.203.1557935706193; Wed, 15 May 2019 08:55:06 -0700 (PDT)
Received: from [10.95.92.20] ([162.210.129.5]) by smtp.gmail.com with ESMTPSA id u38sm8634327pgn.73.2019.05.15.08.55.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 May 2019 08:55:05 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
From: tony.li@tony.li
Message-Id: <34E9B363-8D42-400B-A176-3E305B435410@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8C573DD5-F682-445C-9A21-2DD2CA0017F5"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Wed, 15 May 2019 08:55:04 -0700
In-Reply-To: <5316A0AB3C851246A7CA5758973207D463BB6CF3@sjceml521-mbx.china.huawei.com>
Cc: "lsr@ietf.org" <lsr@ietf.org>
To: Huaimo Chen <huaimo.chen@huawei.com>
References: <5316A0AB3C851246A7CA5758973207D463BB6CF3@sjceml521-mbx.china.huawei.com>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/3a6ci3m8-z6FgUlttSW0dFRGc5M>
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, 15 May 2019 15:55:09 -0000

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