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

Nandan Saha <nandan@arista.com> Tue, 20 August 2019 14:49 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 7C7761208D1 for <idr@ietfa.amsl.com>; Tue, 20 Aug 2019 07:49:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jXmvcKw-UHjP for <idr@ietfa.amsl.com>; Tue, 20 Aug 2019 07:49:38 -0700 (PDT)
Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) (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 4D264120878 for <idr@ietf.org>; Tue, 20 Aug 2019 07:49:38 -0700 (PDT)
Received: by mail-oi1-x242.google.com with SMTP id g7so4282497oia.8 for <idr@ietf.org>; Tue, 20 Aug 2019 07:49:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=googlenew; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=diHqQ4d3toEHVsLE+Ed33okqXxmfmlGf3afWwkfZ7RI=; b=GdGvEil901+vRsrLye/nRjcPfvFici32oMiW8fE+qqlFts7GjHX29xF0Y/XNVDUs0h Khl1QVOuscOFip3IzbfiWmmUz0fPl1Qs3EPe/bSSqLmOfVXhf7ByRoK3mQazHRxRqkDm 0IDldBuhXZ6lvL2fzkiMjP0PNMvSU7NZoh7jivwMUsc8sh3vQyXKr2ruvoGKfVwP5YD8 RkD2p4clLYRWCemSrSVOzV5BM1vZRYmih0fXGGMOqnXNm/cIcYc1A5hBgQtARVDln1YA Gmu2vJpxkQ4YGwAQtKHcyFmSDyF+TP3abILgVOpcIbpRRc7zr1qhTH3hg6qfVIapIyl+ OsUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=diHqQ4d3toEHVsLE+Ed33okqXxmfmlGf3afWwkfZ7RI=; b=Lic+e+pXJleUO2VyilLuYftHd+mVLrjVTBwMmwVAln7jRF9oj+J0dsN7vTibT6e2Od P2qa8rhJwAM8jk01efjC7Qxjr8Y0g5c7JBvQqYdSu9VH9MauSuxI6C5umhZGrX235mA9 ZF9u0voEwr9sRFHymLMvyHJvS9MaW9jAxpsKMw0xmYelsDouFZDhW9yY/CkZ9KX0sCZO S7fpCqaWcVlLsJ4HJ7kKdkv85NlAvFdJHXjYzs+9tj5Qdl1+rOSEoahErojP7hwaqMMR nR3M/20y9JhkC3CNka/si0KR5PrgUoIFdfbLo123VUFPcS349+/H9ZH2dGq23wH9GT3H Dcwg==
X-Gm-Message-State: APjAAAUgBiUQBaN6w/3Ayi/sIXTL9aey6aKWHCB74Z/MGmgzpJ0h4PDG INw8BcaaB057spBpoorcDpp6OgmrdzGhkmInP9kC2A==
X-Google-Smtp-Source: APXvYqxeAbmx1pGhQPl4pudzLNQiHw0Bv+jstVOtKwwRaedpVOSpjwsRzEBI7Lfblw9lNNcslyfwbZL9kFVlT8MVh4Q=
X-Received: by 2002:a05:6808:359:: with SMTP id j25mr280642oie.146.1566312577286; Tue, 20 Aug 2019 07:49:37 -0700 (PDT)
MIME-Version: 1.0
References: <CAE+itjcPpoywOhJHHLbXfYw=j4oYy7FpWrepfzcNWcUU+Stcsg@mail.gmail.com> <CY4PR11MB15418CB0DBEF63C7197F8376C1AB0@CY4PR11MB1541.namprd11.prod.outlook.com>
In-Reply-To: <CY4PR11MB15418CB0DBEF63C7197F8376C1AB0@CY4PR11MB1541.namprd11.prod.outlook.com>
From: Nandan Saha <nandan@arista.com>
Date: Tue, 20 Aug 2019 20:19:25 +0530
Message-ID: <CAE+itjeczuvzSnE01CSB-ei-KLCCGZm6XeOx7yM6prYUBLRFzg@mail.gmail.com>
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
Cc: "draft-ketant-idr-rfc7752bis@ietf.org" <draft-ketant-idr-rfc7752bis@ietf.org>, "idr@ietf.org" <idr@ietf.org>, Prakash Badrinarayanan <prakash@arista.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/0k3TjUehKvOM629Nq-w2b0Jk3k8>
Subject: Re: [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 14:49:41 -0000

On Tue, Aug 20, 2019 at 8:11 PM Ketan Talaulikar (ketant)
<ketant@cisco.com> wrote:
>
> Hi Nandan,
>
> Thanks for your review and comments. All of these are for the existing RFC7752 content and we'll try to address them in the bis draft.
Thanks for the prompt response Ketan.
About my narrow metric comment, I misread the text as "2 bytes" rather
than "2 bits". So it's fine to leave the text as is also.
Ack on the rest.

Thanks,
Nandan
>
> Please check inline below.
>
> -----Original Message-----
> From: Nandan Saha <nandan@arista.com>
> Sent: 20 August 2019 19:17
> To: draft-ketant-idr-rfc7752bis@ietf.org
> Cc: idr@ietf.org; Prakash Badrinarayanan <prakash@arista.com>om>; Ketan Talaulikar (ketant) <ketant@cisco.com>
> Subject: Some questions and comments on draft-ketant-idr-rfc7752bis
>
> 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.
> [KT] Agree that the size is 1 byte and will fix this.
> 1.2) Nit: In the context of IS-IS, overload and attached aren’t “capabilities”, to me at least they represent operational/network state.
> [KT] Ack
>
> 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.
> [KT] The length is 1 octet and the two MSB bits are to be ignored because the range is 1-63 for narrow metrics in ISIS. Perhaps for clarity, we MUST set the two significant bits to 0.
> (Or) should narrow metrics be sent with length=3 and most significant
> 2 bytes set to 0?
> [KT] Size is 1 octet.
>
> 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.
> [KT] Agreed. When used as a descriptor TLV, the flags MUST be set to 0 while when used as Node attribute these flags are used to indicate overload or attached. Will clarify this in the text.
>
> 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.
> [KT] There is no padding anywhere in the picture here. When there is padding, it is specifically indicated as such using reserved field or explicitly in the text. IMHO the diagram and text is clear on this.
>
> Thanks,
> Ketan
>
>      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