Re: [Idr] Possibility of empty Link Descriptors in BGP-LS?

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Fri, 01 November 2019 18:22 UTC

Return-Path: <ketant@cisco.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 C039D12105E; Fri, 1 Nov 2019 11:22:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=Tx4A6OKY; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Js6ULBYW
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 7aD7tAAtQ-Ym; Fri, 1 Nov 2019 11:22:25 -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 4E0A712107A; Fri, 1 Nov 2019 11:22:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21442; q=dns/txt; s=iport; t=1572632545; x=1573842145; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=j8JA16kSC4rgDQX1eSGOfzo1aacVZRcQclJZzbWnlEg=; b=Tx4A6OKYQVJ41UImlPq9kR7URRsaCY9wdmpPmcsPzv78IvXsSESgoyZ2 TvMflt6u8WzBuD5hOikwKLjtxPvvjFxtlXwRf7K7P2CN13ZPY/mCWdQVD m7GWb7PG8c1tmeqfD9PZSQKgHtjSiqGaGv68HGGKyZvJBPhxdEjNltCuY k=;
IronPort-PHdr: 9a23:UNf/gxYCuM0IhsHg5jjxWpb/LSx94ef9IxIV55w7irlHbqWk+dH4MVfC4el20Q6bRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn1NksAKh0olCc+BB1f8KavpYjAzGthqX15+9Hb9Ok9QS47z
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0B1AAB6d7xd/4sNJK1bChsBAQEBAQEBBQEBAREBAQMDAQEBgWwDAQEBCwGBGy8kLAVsWCAECyqEKINGA4p0gl6TG4RhglIDVAkBAQEMAQElCAIBAYRAAheDZCQ3Bg4CAwsBAQQBAQECAQUEbYU3DIVRAQEBAQMSEQoTAQE3AQsEAgEIEQQBASgDAgICMBQJCAIEDgUIGoMBgXlNAy4BDqdtAoE4iGB1gTKCfgEBBYE4AoNaGIIXAwaBNgGMEBiBQD+BEAFGgh4uPoJiAQECAYEzLSQHCYJaMoIsj32FPIk5jwQKgiSHEY4/mWWWbpEmAgQCBAUCDgEBBYFoI4FYcBWDJ1ARFIMGg3OFFIU/dAEBgSaNRAEB
X-IronPort-AV: E=Sophos;i="5.68,256,1569283200"; d="scan'208,217";a="657351041"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Nov 2019 18:22:24 +0000
Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id xA1IMOSp031292 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Nov 2019 18:22:24 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 1 Nov 2019 13:22:23 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 1 Nov 2019 13:22:23 -0500
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 1 Nov 2019 14:22:23 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WhZ4YYNGQOm/1GWJq4Epppb1QVgm1J8uUPuO1xuvmK/QwJ4yYvrY1v/Mjs+CHroKtENQKCgn1tpGgdNz6GNKsz2eXS+KicCjus2VZemUUnu8n7PfW0AELpYx4Gc78kwn94nxXXou5TiIA45yVrMSe6nAXW4kjpFkiFXJe/23m4/g7PViWYCSOb22z7HifB0Jt4RhT04XXmEkF+9Hj/o5JU2pPRPTVpsLBsuIU9wwvavnSCVspnxq23F4EI9vz4X+YafU37vNKFDLs6y+BV+BmZ6BavASeqK2Ri1UY5olAqEnQ6Gh7t62CQKxxIJebFp4/IN260TDtAH5TJ4PlLaINw==
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=j8JA16kSC4rgDQX1eSGOfzo1aacVZRcQclJZzbWnlEg=; b=iR27AoyHqf1oQrhLwSema/d2s/lO+Wc1Zgt+Lz7L/bAU/CZQV4cpCfSNu/Q2urjMJ9FeIDZ2Ce+JsFdGZf2BoKpaWYf7nSxHwUoaJpKiB8Qz6shHRSGIzytypf2Djb+m7xHH3IR66ap1GX8B9g6lC7dVMKEyrgHZNwJXAgOHKrQPBXQ7diXuX3NoJaNgxFsMRP7HRnb9M1bn3Fgb9rj/9vWdchh2ghLXvcSKOsG9bfvywmd9vBxtiza7CBWfbWCBn5XgrwYolc4ijH1xbB9cKYbZGzs6/u4Q/sIDttgaldnWeA5ZQ8PDnML2o1Wz+SUmgLUVdLkZgoDJgEx1FS1xwg==
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=j8JA16kSC4rgDQX1eSGOfzo1aacVZRcQclJZzbWnlEg=; b=Js6ULBYW+WcbaASDT5nbeotZK6cG5PyZUWQ1dd7umMzbIetoxabUCslDUXQDWBuLp5MBz2RC2VwQcKjH5YH5HTiz2oYL86zwHez53coTgfTHAGSiGN1vd8iDelMcpgGqnVBr7t4xYFzSe6aLa0x245mJVKPdc71zbTOx+TTZs5k=
Received: from CY4PR11MB1541.namprd11.prod.outlook.com (10.172.68.150) by CY4PR11MB1816.namprd11.prod.outlook.com (10.175.63.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.23; Fri, 1 Nov 2019 18:22:21 +0000
Received: from CY4PR11MB1541.namprd11.prod.outlook.com ([fe80::d3a:84a6:be65:e33f]) by CY4PR11MB1541.namprd11.prod.outlook.com ([fe80::d3a:84a6:be65:e33f%11]) with mapi id 15.20.2387.028; Fri, 1 Nov 2019 18:22:21 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Nandan Saha <nandan@arista.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>
Thread-Topic: Possibility of empty Link Descriptors in BGP-LS?
Thread-Index: AQHVV3Mg6aQ+9Yqes06kpGmJmU1iyacEQT/AgCmh2gCAJMMMMIAAHa6AgCRPsnA=
Date: Fri, 01 Nov 2019 18:22:21 +0000
Message-ID: <CY4PR11MB1541625F0FDC2BBA135917B3C1620@CY4PR11MB1541.namprd11.prod.outlook.com>
References: <CAE+itjfxH1tmgmfOAwFmT3n-5s_Zu_nVqTjybbp=9L1F1Wea7w@mail.gmail.com> <CY4PR11MB15416D84C646DDCA17DFB777C1AB0@CY4PR11MB1541.namprd11.prod.outlook.com> <CAE+itjfBRL0S7=N2kzHOsHDrcPL-OANw3tZfDiguXw0SupBLzw@mail.gmail.com> <CY4PR11MB15415121B84FA55CB4F0B8E6C1950@CY4PR11MB1541.namprd11.prod.outlook.com> <CAE+itjfPYdRoj6WFmDn1NF8wpGn2HH76m9gqirWaQa0gDipq4g@mail.gmail.com>
In-Reply-To: <CAE+itjfPYdRoj6WFmDn1NF8wpGn2HH76m9gqirWaQa0gDipq4g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ketant@cisco.com;
x-originating-ip: [2405:201:1800:c766:3561:9fe4:5e7b:45f6]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a1881796-35a8-4a0e-c24c-08d75ef86f8e
x-ms-traffictypediagnostic: CY4PR11MB1816:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <CY4PR11MB1816ED5D1EF03E8D65BE7484C1620@CY4PR11MB1816.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 020877E0CB
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(346002)(136003)(376002)(396003)(13464003)(189003)(199004)(52284002)(5660300002)(33656002)(46003)(55016002)(478600001)(81156014)(966005)(81166006)(99286004)(52536014)(25786009)(6246003)(4326008)(229853002)(316002)(102836004)(14454004)(186003)(53546011)(6506007)(6436002)(7520500002)(86362001)(71190400001)(71200400001)(8676002)(790700001)(6116002)(7696005)(6916009)(74316002)(8936002)(256004)(6306002)(9686003)(54896002)(76116006)(2906002)(606006)(66446008)(486006)(66946007)(9326002)(11346002)(476003)(64756008)(54906003)(66476007)(66556008)(236005)(446003)(76176011)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR11MB1816; H:CY4PR11MB1541.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
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: Fdy4GCc+EZd/SrROkZ6CatPk/9UyTto7xU3KOl0AB9Puh9tVr00x6JYDC2IaIasWCP6Ti+szI40L/EhzvYKdsZiiLwelDI82QI+/KcGP2Ywbstqwla1G+lnRALPsRZfj/KUzQuVeVIEbsJppUlbSAoT/qN/mn78GYkHX/82Fo1Tet5Ey8p8jBAV+IVxyDmyZzar42gkbc7WTHB4NB0acc1WiR11Fad+DFMxlMfndSpwp1//06/VxtTMkwR7viPRopf+dmkqL2JVzwIkklIrK+WImCL22g/PxO/gMdPGZmDFNqTFTWP1iY76ftmYPw2JX9+1J+R1He9cX/6tTm8mQG927QQjGSF52QWM+1h4DJVGDul2Wzr1RCCOwChLhkbT8P0WORoISbZ0yEU79ftSFnPFbvGTLa1cTXaXh0+WcV9BqGFDkWmPaFjZzkK0gx2i/cNIZaRWeEMdmutK2UAjUNHHgdy/KS2SKTf76pSSoYes=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CY4PR11MB1541625F0FDC2BBA135917B3C1620CY4PR11MB1541namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a1881796-35a8-4a0e-c24c-08d75ef86f8e
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2019 18:22:21.0682 (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: gicb7kcu9TCvEr+3eBHG/eY3+DTHXHrHDFxWg7JMGipiGshBzlUERWI1dTktyBUdmA6wnz+XDZhG/KSUK1Evfg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB1816
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/tJd6eKLxLB6ouTT0zAARFBs0ni8>
Subject: Re: [Idr] Possibility of empty Link Descriptors in BGP-LS?
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: Fri, 01 Nov 2019 18:22:34 -0000

Hi Nandan,

An updated version has been posted to address your comments as discussed below.


https://tools.ietf.org/html/draft-ietf-idr-rfc7752bis-02

Thanks,
Ketan

From: Nandan Saha <nandan@arista.com>
Sent: 09 October 2019 21:21
To: Ketan Talaulikar (ketant) <ketant@cisco.com>
Cc: draft-ketant-idr-rfc7752bis@ietf.org; idr@ietf.org; Prakash Badrinarayanan <prakash@arista.com>
Subject: Re: Possibility of empty Link Descriptors in BGP-LS?

Hi Ketan,

On Wed, Oct 9, 2019 at 7:52 PM Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>> wrote:
Hi Nandan,

How about adding the following text in Sec 4.2.2?

The TLVs/sub-TLVs corresponding to the interface addresses and/or the local/remote identfiers may not always be signaled in the IGPs unless their advertisement is enabled specifically. In such cases, a BGP-LS Producer may not be able to generate valid Link NLRIs for such link advertisements from the IGPs.
Sounds good!

Thanks,
Ketan

From: Nandan Saha <nandan@arista.com<mailto:nandan@arista.com>>
Sent: 16 September 2019 10:11
To: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>
Cc: draft-ketant-idr-rfc7752bis@ietf.org<mailto:draft-ketant-idr-rfc7752bis@ietf.org>; idr@ietf.org<mailto:idr@ietf.org>; Prakash Badrinarayanan <prakash@arista.com<mailto:prakash@arista.com>>
Subject: Re: Possibility of empty Link Descriptors in BGP-LS?

Hi Ketan,
    Thank you for your patience. I thought I had replied to this, but somehow hadn't.
On Tue, Aug 20, 2019 at 11:31 PM Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>> wrote:
Hi Nandan,

You are correct that an ISIS implementation (in non-TE/SR) environment will not advertise the necessary link descriptors without which it will not be possible to describe links completely. It is not just about empty link descriptors, but when there are parallel links, they will end up overwriting each other's attributes in BGP-LS as those NLRIs would get mixed up. IMHO it does not serve much purpose advertising such links via BGP-LS.

What text would you suggest we add in the BGP-LS specification for this?
Something along the lines that a BGP-LS producer may not be able to generate valid link NLRIs in the absence of the required sub-TLVs in the IGP. I'm mostly thinking from the point of view of guiding operators that the IGP needs to be configured appropriately.
I'm not fully in agreement about leaving out such links. In the case there's only one p2p link between devices we'll simply be losing information in BGP-LS, since it's possible to identify such a link uniquely. (Though it's an academic discussion since most deployments are likely to use bgp-ls for TE)
In anycase, I don't feel too strong about adding new text in case you feel it's obvious from the rest of the text.

Thanks,
Ketan

-----Original Message-----
From: Nandan Saha <nandan@arista.com<mailto:nandan@arista.com>>
Sent: 20 August 2019 21:48
To: draft-ketant-idr-rfc7752bis@ietf.org<mailto:draft-ketant-idr-rfc7752bis@ietf.org>; idr@ietf.org<mailto:idr@ietf.org>
Cc: Prakash Badrinarayanan <prakash@arista.com<mailto:prakash@arista.com>>; Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>
Subject: Possibility of empty Link Descriptors in BGP-LS?

Hi folks,

I'm wondering whether some text needs to be added to
https://tools.ietf.org/html/draft-ketant-idr-rfc7752bis-01#section-4.2.2
for the case where neither the ipv4/6 address sub tlvs nor link/remote identifiers are present in the IGP's LSP/LSA.
For IS-IS specifically, it seems to me that an IS-IS implementation (in a non-TE) scenario is free to leave out the ipv4/6 interface/neighbor address sub-tlvs based on https://tools.ietf.org/html/rfc5305#section-3.2, and https://tools.ietf.org/html/rfc5305#section-3.3. The link/remote link identifiers also appear optional.

In such a case, the link descriptor in the link nlri will be empty which is problematic in the case where there are multiple links between 2 nodes as there's no way to distinguish between the different links.

Thanks,
Nandan