Re: [Lsvr] Need clarification on IGP-Metric TLV for LS Link Attributes in BGP-SPF deployments

Pushpasis Sarkar <pushpasis.ietf@gmail.com> Thu, 26 March 2020 20:28 UTC

Return-Path: <pushpasis.ietf@gmail.com>
X-Original-To: lsvr@ietfa.amsl.com
Delivered-To: lsvr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15C03A0E80; Thu, 26 Mar 2020 13:28:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 73NwhenbPPUo; Thu, 26 Mar 2020 13:28:37 -0700 (PDT)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 E552A3A0A9F; Thu, 26 Mar 2020 13:28:35 -0700 (PDT)
Received: by mail-ed1-x536.google.com with SMTP id a20so8542362edj.2; Thu, 26 Mar 2020 13:28:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1Pi+plYHkp8EZd11dgbWBlqocovbOKJYukejjszRrFY=; b=mvu4WphfMkfKwCb/lhXm8ve6qxZoo7ONrCKpOzY+blOPgMMZjFHL3d8JuKXXklci2b XtsURfghAzZe29BpawUm2aAO+BLv58tHwKFUncEt9znaqE7nzZlOM/baVkozT5fsYtIa eLX12abbXIHcup8DvdSYuraV81DeG3/FSR+U5zrQDPJp9s9iyrkL7/p0WvGQJ5ru+r+z N3617myE4Ht3y5UkwAegglZFlwO1PLjJCiMkVEM+4ZsqqipaynywRthOo37A+HTXFvHE EpU3xTpWb7oMJlTIFiC+HfSRUtJXkTIIk+a9bHFo0wOLm0G8dlsFAQigdHQk3Nk4gYNB qllQ==
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; bh=1Pi+plYHkp8EZd11dgbWBlqocovbOKJYukejjszRrFY=; b=iIo5mb9nB07VMVY6cgghgLkASyB0IJny2xTJym0jaIOY6t+s0QRj/d4aPrgVmKq9AT fdZFuqhdoYvF6WBmwkoKKcbr4r+ysBS9LXyYYrD4pDRdD0yNDjLDeXoCk33S18wcGN6w GUP56gcWu0hXnZq+Kpii9n26M1pVW7WdWHY/Zsdlh+YlAxsfdbL+3mnS66ugEjfWhPES kk6WVsCm5OeQPtftldKewfxp/JP4CpAA1qU7rS3xRgAymvg/w8vPewQXSDSEtKunGSXk aQambE8ST2hQxJVPtJZNyVmQBg4ppvAYnkjxarQPiNgXdSJjawA0fZkG3AE/lfxwHMdI BjkA==
X-Gm-Message-State: ANhLgQ3JvXenZt4T3SUQXpsTU78U6ckVcPKenZmC82+nLo2ZYUveThWL 4E84HL+JGhw/NbPAuW6eIemTjAeneeinAnx+nnDDhA==
X-Google-Smtp-Source: ADFU+vt25C7/w7NktMtDl2ibL+cN4ozi2q7Px0VGm4lq8WwgzwyrslpAmjPX5PLuNvzmDD7KZSKXLuUA+CGhQe6Eg0s=
X-Received: by 2002:a17:906:b212:: with SMTP id p18mr9754094ejz.59.1585254514145; Thu, 26 Mar 2020 13:28:34 -0700 (PDT)
MIME-Version: 1.0
References: <CAEFuwkh=zmq_W_DD_MLePtc2pAZY7T1aENbbE01_cU588ZxDxQ@mail.gmail.com> <7DFD0D7F-65FC-4032-BCD2-7A2A1CA44512@cisco.com> <CAEFuwkjL2-LkLeLv1UYS4ZCcjEZF5RHtiH=sD=hqtrqMVUAacg@mail.gmail.com> <8FF70B9D-58AF-4A92-BD43-C55186C3A8DB@cisco.com> <CAEFuwkiJ_Z6+BBHPnQqYymji0mDmANJc=M3iY2pwLrhK581DCg@mail.gmail.com> <140CF301-A548-4FD0-B103-759817A49BA2@cisco.com> <CAEFuwki2BRizisaSkqVPGGrmo9Yc5eTTPArEqWTe6rZjFPVREw@mail.gmail.com> <323B15AE-53FE-4EE5-B4F2-7C189A699EA4@cisco.com>
In-Reply-To: <323B15AE-53FE-4EE5-B4F2-7C189A699EA4@cisco.com>
From: Pushpasis Sarkar <pushpasis.ietf@gmail.com>
Date: Fri, 27 Mar 2020 01:58:23 +0530
Message-ID: <CAEFuwkitf6gEuTrYU_op9H__t3wVfzSmt=XSDjJgTZjF2MZJzA@mail.gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
Cc: "draft-ietf-lsvr-bgp-spf@ietf.org" <draft-ietf-lsvr-bgp-spf@ietf.org>, "lsvr@ietf.org" <lsvr@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000031befe05a1c7d4d5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsvr/bSCgFnOzFkiiCjAn-_51KeTob6E>
Subject: Re: [Lsvr] Need clarification on IGP-Metric TLV for LS Link Attributes in BGP-SPF deployments
X-BeenThere: lsvr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Vector Routing <lsvr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsvr>, <mailto:lsvr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsvr/>
List-Post: <mailto:lsvr@ietf.org>
List-Help: <mailto:lsvr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsvr>, <mailto:lsvr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2020 20:28:58 -0000

Hi Acee,

Thanks a lot for taking care of this.

Best regards
-Pushpasis


On Tue, Mar 24, 2020 at 8:18 PM Acee Lindem (acee) <acee@cisco.com> wrote:

> Hi Pushpasis, et al,
>
> This is clarified in the -08 version of the draft.
>
> Thanks,
>
> Acee
>
>
>
> *From: *Pushpasis Sarkar <pushpasis.ietf@gmail.com>
> *Date: *Sunday, March 22, 2020 at 11:43 AM
> *To: *Acee Lindem <acee@cisco.com>
> *Cc: *"draft-ietf-lsvr-bgp-spf@ietf.org" <draft-ietf-lsvr-bgp-spf@ietf.org>rg>,
> "lsvr@ietf.org" <lsvr@ietf.org>
> *Subject: *Re: Need clarification on IGP-Metric TLV for LS Link
> Attributes in BGP-SPF deployments
>
>
>
> Hi Acee,
>
>
>
> Sure. If anyone doesn't prefer any other way we can proceed with this.
>
>
>
> Thanks
>
> -Pushpasis
>
>
>
>
>
> On Sat, Mar 21, 2020 at 7:49 PM Acee Lindem (acee) <acee@cisco.com> wrote:
>
> Hi Pushpais,
>
> I think we can get away with this w/o modifying RFC 7752 since, as you
> noted, it just says it is variable.
>
> Thanks,
>
> Acee
>
>
>
> *From: *Pushpasis Sarkar <pushpasis.ietf@gmail.com>
> *Date: *Saturday, March 21, 2020 at 10:15 AM
> *To: *Acee Lindem <acee@cisco.com>
> *Cc: *"draft-ietf-lsvr-bgp-spf@ietf.org" <draft-ietf-lsvr-bgp-spf@ietf.org>rg>,
> "lsvr@ietf.org" <lsvr@ietf.org>
> *Subject: *Re: Need clarification on IGP-Metric TLV for LS Link
> Attributes in BGP-SPF deployments
>
>
>
> Hi Acee,
>
>
>
> I thought RFC7752 says it is a variable length TLV. 1-byte, 2-byte, and
> 3-byte metrics are possible lengths. Can't we add a 4th possible length via
> this draft? If not then a new TLV may be a better option.
>
>
>
> However if I remember correctly, there is a RFC7752 bis being worked upon.
> Is there an option we can add it in that document? Not sure if it will be a
> proper way or not. Just thinking out loud :)
>
>
>
> Thanks
>
> -Pushpasis
>
>
>
>
>
> On Sat, Mar 21, 2020 at 7:17 PM Acee Lindem (acee) <acee@cisco.com> wrote:
>
> Hi Pushpasis,
>
> If we use a length of 4, we’d need a new TLV (or modify RFC 7752). I think
> the former would be a better option.
>
> Thanks,
>
> Acee
>
>
>
> *From: *Pushpasis Sarkar <pushpasis.ietf@gmail.com>
> *Date: *Saturday, March 21, 2020 at 9:00 AM
> *To: *Acee Lindem <acee@cisco.com>
> *Cc: *"draft-ietf-lsvr-bgp-spf@ietf.org" <draft-ietf-lsvr-bgp-spf@ietf.org>rg>,
> "lsvr@ietf.org" <lsvr@ietf.org>
> *Subject: *Re: Need clarification on IGP-Metric TLV for LS Link
> Attributes in BGP-SPF deployments
> *Resent-From: *<alias-bounces@ietf.org>
> *Resent-To: *Keyur Patel <keyur@arrcus.com>om>, Acee Lindem <acee@cisco.com>om>,
> Shawn Zandi <szandi@linkedin.com>om>, Wim Henderickx <
> wim.henderickx@nokia.com>
> *Resent-Date: *Saturday, March 21, 2020 at 9:00 AM
>
>
>
> Hi Acee,
>
>
>
> My personal preference will be having it as a 4-byte metric due to ease of
> implementation as well as encoding/decoding efficiency due word-size
> alignment. It may not be a big thing but encoding/decoding a 3-byte value
> to/from byte stream is few more CPU instructions than just a 4-byte read
> from a memory address.
>
>
>
> Thanks
>
> -Pushpasis
>
>
>
> On Sat, Mar 21, 2020 at 12:10 AM Acee Lindem (acee) <acee@cisco.com>
> wrote:
>
> Hi Pushpasis,
>
> I think for BGP-LS SPF we should always use 3 octet metrics. This will
> offer the most flexibility w/o redefining the TLV. If you agree, I will
> update the SPF draft to state this.
>
> Thanks,
>
> Acee
>
>
>
> *From: *Pushpasis Sarkar <pushpasis.ietf@gmail.com>
> *Date: *Monday, March 9, 2020 at 11:31 AM
> *To: *"draft-ietf-lsvr-bgp-spf@ietf.org" <draft-ietf-lsvr-bgp-spf@ietf.org
> >
> *Cc: *"lsvr@ietf.org" <lsvr@ietf.org>
> *Subject: *Need clarification on IGP-Metric TLV for LS Link Attributes in
> BGP-SPF deployments
> *Resent-From: *<alias-bounces@ietf.org>
> *Resent-To: *Keyur Patel <keyur@arrcus.com>om>, Acee Lindem <acee@cisco.com>om>,
> Shawn Zandi <szandi@linkedin.com>om>, Wim Henderickx <
> wim.henderickx@nokia.com>
> *Resent-Date: *Monday, March 9, 2020 at 11:31 AM
>
>
>
> Hi Authors,
>
>
>
> I need a small clarification on how the Link IGP-Metric TLV (type 1095)
> for the links originated by an BGP-SPF speaker look like. My doubt is
> specifically on what would be the length of the metric value. For example,
> following is the excerpt from RFC7752 section 3.3.2.4 which specifies the
> length to be 1, 2 or 3 bytes for ISIS narrow-metrics, OSPF and ISIS
> wide-metrics.
>
>
>
> 3.3.2.4.  IGP Metric TLV
>
>
>
>    The IGP Metric TLV carries the metric for this link.  The length of
>
>    this TLV is variable, depending on the metric width of the underlying
>
>    protocol.  IS-IS small metrics have a length of 1 octet (the two most
>
>    significant bits are ignored).  OSPF link metrics have a length of 2
>
>    octets.  IS-IS wide metrics have a length of 3 octets.
>
>
>
>       0                   1                   2                   3
>
>       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
>
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>      |              Type             |             Length            |
>
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>      //      IGP Link Metric (variable length)      //
>
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>                      Figure 21: IGP Metric TLV Format
>
>
>
> What should be the length of the metric field when the origin is a BGP-SPF
> speaker?
>
>
>
> Looking forward to your clarification on this. Also it will be appreciated
> a lot if a sentence or two can be added to the draft clarifying the above
> in the next version.
>
>
>
> Thanks and regards,
>
> -Pushpasis
>
>
>
>