[Idr] Some questions and comments on draft-ketant-idr-rfc7752bis

Nandan Saha <nandan@arista.com> Tue, 20 August 2019 13:46 UTC

Return-Path: <nandan@arista.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8C93012094D for <idr@ietfa.amsl.com>; Tue, 20 Aug 2019 06:46:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=arista.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id oIiqBPmQWJRm for <idr@ietfa.amsl.com>; Tue, 20 Aug 2019 06:46:49 -0700 (PDT)
Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 5A05112092B for <idr@ietf.org>; Tue, 20 Aug 2019 06:46:49 -0700 (PDT)
Received: by mail-ot1-x336.google.com with SMTP id g17so5066933otl.2 for <idr@ietf.org>; Tue, 20 Aug 2019 06:46:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=googlenew; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=gcmUCX75xXX1zdBnWV3SHk5IO0qsFvN++XSoUQiKslE=; b=WMLvDKg8v0bRh3RRiDGpfu+l5tQ7q/Rki4X4kJiL1zO/b22TXoqTADHF1R+Hfl0F3F fZ07i8OW4XUej6OTZJ7jCL9BtDuoBmTAO7781SEHLoJr18wEupe7FNykBC0q0WwSfpfL A+0NUV3ExGRT4tjHrjkyNYDSHy8muy0wqEuqUdpsbvSDtpr3Y7uOWq8WuDM/ifCtv482 w3Te7M1x/XC0M7IKVWu2ApE6VJaCyQBs6JWnUuPYfvx7psaEOMqUV8pRba+RopAO21y9 HaT7QGQ4wXiTbiOuYoV3AThmTCkD6ufNoS5l9AQ1JiPzudxOHyi4TVP51xUP3JMtqOgM 5/AQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=gcmUCX75xXX1zdBnWV3SHk5IO0qsFvN++XSoUQiKslE=; b=PtB5XAsHjwlXG2uxtQXCVFONVmt6QVhy/VFvGDh++nWTcl0mXSmK36XuW5DVgyhJhF Rh6UL2gdq5kKuwkr3QJyGJEpJqjqeCd1bkGbRi8loJbMZTcuaC70+OPHGPdpVCzqH+jJ ilIIu5UNYWhUnUukpI6GUoRaQAyIANKqKL0sWmFqk0C2PrGmJWZozZKW6Cv3MqsiCnrH RECidSMBdwsGEEaJXBLJjIi+F1dIrxYlpA73yz+0yyY8bM5ZwJQS/9LjdjOPA/ryfvAk wlVKu7HyEpHCHexiSliIm5CFW1VHy56JiuErHzH9C5jA4k9utp5TlYzryUrmg0oUSYwG 708A==
X-Gm-Message-State: APjAAAWGt1Td0ynJRfrhzP1jCK78kbYH9GbnwZ8PutGJMejtbS9YjHi6 6lJLWN3Zo5OUiikgOrryzAi9W2wD/mIIkb3+oVRjfw==
X-Google-Smtp-Source: APXvYqzNyVCBQGBOHSEqddK2EKIgEzW6OYohvTBBAxOV4J7OqTvAWQ3R7Q5GGGNMbmYpp3dk35Vm8zoHR+b/LROuPwI=
X-Received: by 2002:a9d:69d7:: with SMTP id v23mr14992006oto.321.1566308808410; Tue, 20 Aug 2019 06:46:48 -0700 (PDT)
MIME-Version: 1.0
From: Nandan Saha <nandan@arista.com>
Date: Tue, 20 Aug 2019 19:16:36 +0530
Message-ID: <CAE+itjcPpoywOhJHHLbXfYw=j4oYy7FpWrepfzcNWcUU+Stcsg@mail.gmail.com>
To: draft-ketant-idr-rfc7752bis@ietf.org
Cc: idr@ietf.org, Prakash Badrinarayanan <prakash@arista.com>, "Ketan Talaulikar (ketant)" <ketant@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/fKvWSq10VSsINXJEw2a-d9fYv6Q>
Subject: [Idr] Some questions and comments on draft-ketant-idr-rfc7752bis
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Aug 2019 13:46:56 -0000

Hi authors,

Had some questions and comments on draft-ketant-idr-rfc7752bis. Some
of the stuff isn't specific to the new/revised content in
draft-ketant-idr-rfc7752bis versus rfc7752 and likely applies to
rfc7752 as well.

1. https://tools.ietf.org/html/draft-ketant-idr-rfc7752bis-01#section-
The value is a variable-length bit array of flags, where each bit
represents a node capability
1.1) The value does not appear to be variable length as the size is
fixed to 1 byte.
1.2) Nit: In the context of IS-IS, overload and attached aren’t
“capabilities”, to me at least they represent operational/network

2. What is the length to be used for IGP Metric TLV
for IS-IS narrow metrics.
IS-IS small metrics have a length of 1 octet (the two most significant
bits are ignored).
What is the intent of the text in brackets since the length will be
set to 1 when narrow metrics is used, so only one octet will be
(Or) should narrow metrics be sent with length=3 and most significant
2 bytes set to 0?

3. 'O', 'A' bit missing from MT-ID TLV when used as a node attribute
Table 6 in https://tools.ietf.org/html/draft-ketant-idr-rfc7752bis-01#section-4.3.1
points to section- where the MT-ID TLV is defined as per
https://tools.ietf.org/html/rfc5120#section-7.2 where the flags are
all reserved. This is fine from the point of view of link, prefix
information. However in IS-IS in LSP fragment 0, when the MT-IDs are
carried in TLV 229 (https://tools.ietf.org/html/rfc5120#section-7.1),
the overload and attached bits have meaning. So shouldn’t the bgp-ls
definition also carry them when carried as a Node attribute to
indicate overload or attached for that MT.

4. Is there any padding in the Node, Link, Prefix NLRIs ?
It's not clear to me from figures 7,8, 9 in
whether there's 3 bytes of padding / reserved between "Protocol-ID"
and "Identifier". If there is, it'll be good to mention that it needs
to be set 0. If not, then it'll be good to maybe add some text to
indicate that Identifier immediately follows the Protocol-ID because
IMO someone reading this can interpret it either way.

     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     |  Protocol-ID  |  <Is this portion 3 bytes of padding?>
     |                           Identifier                          |
     |                            (64 bits)                          |