[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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-4.3.1.1 <QUOTE> The value is a variable-length bit array of flags, where each bit represents a node capability </QUOTE> 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 state. 2. What is the length to be used for IGP Metric TLV (https://tools.ietf.org/html/draft-ketant-idr-rfc7752bis-01#section-4.3.2.4) for IS-IS narrow metrics. <QUOTE> IS-IS small metrics have a length of 1 octet (the two most significant bits are ignored). </QUOTE> 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 present. (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-4.2.2.1 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 https://tools.ietf.org/html/draft-ketant-idr-rfc7752bis-01#section-4.2, 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thanks, Nandan
- [Idr] Some questions and comments on draft-ketant… Nandan Saha
- Re: [Idr] Some questions and comments on draft-ke… Ketan Talaulikar (ketant)
- Re: [Idr] Some questions and comments on draft-ke… Nandan Saha