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

"Acee Lindem (acee)" <acee@cisco.com> Tue, 24 March 2020 14:48 UTC

Return-Path: <acee@cisco.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 A3B6A3A0A90; Tue, 24 Mar 2020 07:48:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.596
X-Spam-Level:
X-Spam-Status: No, score=-9.596 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=mDvu7ByT; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ydNzYLE3
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 fWKchKKREWAk; Tue, 24 Mar 2020 07:48:14 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A88A3A0A12; Tue, 24 Mar 2020 07:48:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42273; q=dns/txt; s=iport; t=1585061294; x=1586270894; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qzG+kSWqsRNQbVK4PvtU38mU9YRdV71atzqs+bB8lhU=; b=mDvu7ByTzLqyCHBOkaC859WW89PjMuV/y7QBU88iEXJXMRKkEr3NBlyq KVETRkK86vD+xii0QgylWtn4mpQvcBdijhr79Dfsb9vblEC1Eu3NcuGOZ 66gr3hd3u45SnFPfNtA7NnaPSr56ktggbE/JWzyBx0v5UN5/DOH7mw5zF U=;
X-IronPort-AV: E=Sophos;i="5.72,300,1580774400"; d="scan'208,217";a="742322844"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Mar 2020 14:47:47 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 02OEllX6007004 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 24 Mar 2020 14:47:47 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 24 Mar 2020 09:47:47 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 24 Mar 2020 09:47:46 -0500
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 24 Mar 2020 10:47:46 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lGGt7KWT95LI08v2tV29tOVsxsaKVcCGpXOXCxWaygHAD+TxOopyasWFlIGhn5N44sReUSo+xFM04eBvIgfmSK7k3kM7sF26NSluy6WufbFS/S5tDLTWAlOf1P4LWdVwmeb0DLsV4glB62anB9K2S6qXfY6D5Js8tsBoWmy3SwQVyWWamTZ4L4ScpivjFtJsStKyVLDqELM4fBKnKBXuL8BaGe5K+NpnwKKYd0fwajxWY19AnKYXPQ+zUwLJFTUnifjsi9PzzHvWCx9A2w5tJmmYcddO0n4EC1pAue9qDpbQbxpi7/r1wZSStuzCXHSdR1wwO+m4zMVBz91OPsjs4w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qzG+kSWqsRNQbVK4PvtU38mU9YRdV71atzqs+bB8lhU=; b=bTXV8K7TyCYkP3bLYnP/9g6p5R+IckE71n20NSbn0rItzZXO4f94AI+NZHQIn00+l6ffVMUSjI3eeI9cJ86oXxBO18vgyYN0DWdGu4ByDjfpdq5MTYzSTiFnEL7IJIFXG3aCtUmY6xEvEsii0XRwMMkzeTqbQWB9iNWWhaUkpC99ABXNBP4RSTToEYJwpWApUZOMIoVlw1D3PThU3OHbWiMixxSq1Im+3eWBGQMiVLI1u9uiribq3HAjWkjYXxR4eFPcFxzJcLcDeqNI+2/NqlQUWKP0Q/AqBxrr/mx8XtBRCoQc3efzRMIwBR8d7PONJkl771rNf+E0CfBVB3uCrw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qzG+kSWqsRNQbVK4PvtU38mU9YRdV71atzqs+bB8lhU=; b=ydNzYLE3R2TMxboXrdGlaG8SJp8U3uViETqyC7wkgfk+qgHXYv6a4lOO3z7V8DX2aYfx4uTGCYK6w2WA0ntwBAZnSMVW5UQgKUj50UF7TSy02vIBknaQvGYFrfMN+ICti9KblEItjoT/RUBUC1Aw+P9CWGBWIfSMP0astOIkudo=
Received: from BN8PR11MB3794.namprd11.prod.outlook.com (2603:10b6:408:8f::13) by BN8PR11MB3634.namprd11.prod.outlook.com (2603:10b6:408:88::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.20; Tue, 24 Mar 2020 14:47:44 +0000
Received: from BN8PR11MB3794.namprd11.prod.outlook.com ([fe80::55b2:c415:675f:5fb7]) by BN8PR11MB3794.namprd11.prod.outlook.com ([fe80::55b2:c415:675f:5fb7%3]) with mapi id 15.20.2835.021; Tue, 24 Mar 2020 14:47:44 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Pushpasis Sarkar <pushpasis.ietf@gmail.com>
CC: "draft-ietf-lsvr-bgp-spf@ietf.org" <draft-ietf-lsvr-bgp-spf@ietf.org>, "lsvr@ietf.org" <lsvr@ietf.org>
Thread-Topic: Need clarification on IGP-Metric TLV for LS Link Attributes in BGP-SPF deployments
Thread-Index: AQHV9ifHldI2Y/pjvUWBbZk/jhUzi6hRnpcAgAF2WwD//8n9gIAASvuA//++KICAAezRgIAC0hiA
Date: Tue, 24 Mar 2020 14:47:44 +0000
Message-ID: <323B15AE-53FE-4EE5-B4F2-7C189A699EA4@cisco.com>
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>
In-Reply-To: <CAEFuwki2BRizisaSkqVPGGrmo9Yc5eTTPArEqWTe6rZjFPVREw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.35.20030802
authentication-results: spf=none (sender IP is ) smtp.mailfrom=acee@cisco.com;
x-originating-ip: [136.56.133.70]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 32c0b6c6-8f5d-4933-ccd2-08d7d0025016
x-ms-traffictypediagnostic: BN8PR11MB3634:
x-microsoft-antispam-prvs: <BN8PR11MB3634263ACD3B6E03EA2A197EC2F10@BN8PR11MB3634.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 03524FBD26
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(366004)(39860400002)(346002)(376002)(33656002)(6506007)(2906002)(36756003)(2616005)(53546011)(6512007)(478600001)(6486002)(45080400002)(54906003)(4326008)(86362001)(5660300002)(316002)(76116006)(66946007)(66556008)(66476007)(66446008)(26005)(64756008)(8936002)(186003)(6916009)(71200400001)(8676002)(91956017)(81156014)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR11MB3634; H:BN8PR11MB3794.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ++G2D2Nx9EEzGRsW6hxWd3mgUUf/aLic4PlgK1tnHmhUfb6JqBw5kbevWYAOYCn7rHDNqMw9MKSqTjo1okZDAJ7OkLb/0eIy/8xjpvh4fwd4EAd6WvLFuL6NQHtgv7tpKW1YcWkhJ+bm4Ax/xQPvSLeewwlkMViBygUoBxMEfisfqpr2OJObiVaZIGANCwRx3SJQPMqNwrDyuBVwYsNl3H9CIiU9JOxGOWnc+HN7bUNv34UzsFkqOk+JOB2wvvZuRzzcA1oSwNZVNomJMIvfNOAwjzD5I5T19c5F0OF4K44u3NCvT2AhhHkSaUqhEk/seJHTE2HzK0c4rGLo9T9mrZWLQtu2SeXAGKmEpWRHHxsSaAd5sxHreigZCQvaIj/mHIU4Xyjm+m70SOeAH7uNE02jE4M0NtbYpW9u/wJt6bAFGb8MI2nQM5jHgQdj7YbT
x-ms-exchange-antispam-messagedata: un3yzVLE2crRdjbGX815+fB21OX4W9ZTOKM2iP8Rv6dGxjhPTlJmTyqiSFvo0yU7qBDNiurr0jGsn8FRipa0hOluK9LM6rD/acOk8M23sZYUSuZ8Se5A+4KZ81ixeMeiaDUrlICdHsEUMtb+3z+Vmw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_323B15AE53FE4EE5B4F27C189A699EA4ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 32c0b6c6-8f5d-4933-ccd2-08d7d0025016
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2020 14:47:44.6089 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: W8oatPwiLCSIOP5qXZBx4CO7/mFdTsdNYiEg7g3TzXWaeE20WBcXA8PERZKJy4fz
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3634
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsvr/dyj7KNhM8rI-tYRP3VRx0HcaIMw>
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: Tue, 24 Mar 2020 14:48:27 -0000

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<mailto: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<mailto:pushpasis.ietf@gmail.com>>
Date: Saturday, March 21, 2020 at 10:15 AM
To: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>
Cc: "draft-ietf-lsvr-bgp-spf@ietf.org<mailto:draft-ietf-lsvr-bgp-spf@ietf.org>" <draft-ietf-lsvr-bgp-spf@ietf.org<mailto:draft-ietf-lsvr-bgp-spf@ietf.org>>, "lsvr@ietf.org<mailto:lsvr@ietf.org>" <lsvr@ietf.org<mailto: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<mailto: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<mailto:pushpasis.ietf@gmail.com>>
Date: Saturday, March 21, 2020 at 9:00 AM
To: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>
Cc: "draft-ietf-lsvr-bgp-spf@ietf.org<mailto:draft-ietf-lsvr-bgp-spf@ietf.org>" <draft-ietf-lsvr-bgp-spf@ietf.org<mailto:draft-ietf-lsvr-bgp-spf@ietf.org>>, "lsvr@ietf.org<mailto:lsvr@ietf.org>" <lsvr@ietf.org<mailto: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<mailto:alias-bounces@ietf.org>>
Resent-To: Keyur Patel <keyur@arrcus.com<mailto:keyur@arrcus.com>>, Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>, Shawn Zandi <szandi@linkedin.com<mailto:szandi@linkedin.com>>, Wim Henderickx <wim.henderickx@nokia.com<mailto: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<mailto: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<mailto:pushpasis.ietf@gmail.com>>
Date: Monday, March 9, 2020 at 11:31 AM
To: "draft-ietf-lsvr-bgp-spf@ietf.org<mailto:draft-ietf-lsvr-bgp-spf@ietf.org>" <draft-ietf-lsvr-bgp-spf@ietf.org<mailto:draft-ietf-lsvr-bgp-spf@ietf.org>>
Cc: "lsvr@ietf.org<mailto:lsvr@ietf.org>" <lsvr@ietf.org<mailto:lsvr@ietf.org>>
Subject: Need clarification on IGP-Metric TLV for LS Link Attributes in BGP-SPF deployments
Resent-From: <alias-bounces@ietf.org<mailto:alias-bounces@ietf.org>>
Resent-To: Keyur Patel <keyur@arrcus.com<mailto:keyur@arrcus.com>>, Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>, Shawn Zandi <szandi@linkedin.com<mailto:szandi@linkedin.com>>, Wim Henderickx <wim.henderickx@nokia.com<mailto: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