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

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Wed, 09 October 2019 14: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 8CD6C12010E; Wed, 9 Oct 2019 07:22:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 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, 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=J4XseL1a; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=UtAS2OiX
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 dny2N2YAuIH6; Wed, 9 Oct 2019 07:22:47 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44ADE120152; Wed, 9 Oct 2019 07:22:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15232; q=dns/txt; s=iport; t=1570630966; x=1571840566; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FW6VDq8qVP3JSTF1IO/J6nwXb95n8jSDYzGdx2vbCSs=; b=J4XseL1ak0mp5NfChnRcKAyCNFablr9T/YOgVYp/FUb+6X9zHN290bNs 331yFciBXjTn2ytZhCkMYrsojx7grfvwcMXL3ELG/8FY5Jp9rgRwtnh/O rZNWzFFsFQ2h9wfmErKmQv3/bM91eKeqj8TNeGqT9xTBrVjeSLa3K+vcE g=;
IronPort-PHdr: =?us-ascii?q?9a23=3Al4UbshGEVKt26aHP+A8bMJ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4w3Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+ef3ncyU8AOxJVURu+DewNk0GUMs=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAACa7J1d/5FdJa1bChoBAQEBAQE?= =?us-ascii?q?BAQEDAQEBAREBAQECAgEBAQGBagIBAQEBCwGBGy8kLANtViAECyoKhBmDRwO?= =?us-ascii?q?KRIJckxyEYYJSA1QJAQEBDAEBJQgCAQGEQAIXgjgjNwYOAgMJAQEEAQEBAgE?= =?us-ascii?q?FBG2FLQyFSwEBAQQSEQoTAQE3AQsEAgEIEQQBASgDAgICMBQJCAIEDgUIGoM?= =?us-ascii?q?BgR1NAx0BDqUZAoE4iGF1gTKCfQEBBYUJGIIXAwaBNAGMDRiBQD+BEAFGgh4?= =?us-ascii?q?uPoJhAQECAYEzLSQHCYJYMoImj2+FN5ghCoIihwiOLJlAlk+RFAIEAgQFAg4?= =?us-ascii?q?BAQWBaCOBWHAVgydQEBSBT4NzhRSFP3QBAYEnkhkBgSIBAQ?=
X-IronPort-AV: E=Sophos;i="5.67,276,1566864000"; d="scan'208,217";a="638082039"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Oct 2019 14:22:45 +0000
Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x99EMiKO017919 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 9 Oct 2019 14:22:45 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 9 Oct 2019 09:22:44 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 9 Oct 2019 10:22:42 -0400
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 9 Oct 2019 09:22:42 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ffb4w3ATmXDP98zX7cnDIlOziYxtn7Ijy6qR7PcAAfxxv+hTc6gLDbxOv5HgMHabZdOCS8qTfffkBvTHQPPxnJ2AgoxMDg9mxgq0xBdgsKs1PdGp0Q6wVR3FO1PVp6Z4xz81/RvgBsPxRbPLNFdSqZRwFcO+3jdKpyxt5yDl3VRnsjPRxvnSFU1XRaD0wHUIMPCx732BtJaoDJFrXBY1z5AagZ52w1pRa955qDXxSCycDuaP7GWteSoj1Asy5aY39UdI73kIvo9zE8eyHojRyUgocGlAmvMrmpwxaNwZVg3vKvSXZ+gxqr72ylafuw/i0eRv8NEk9KWBIf7UKrzLkw==
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=FW6VDq8qVP3JSTF1IO/J6nwXb95n8jSDYzGdx2vbCSs=; b=oJ0HpECMhME28XPT1a6jbSXbm4Nc3QdMMNN0MWBbf5pJCCqVoYHxXojZPGDEi6hl3qJMD5CwrFef0zbn9DI+TXeovLVal1rbwAKVwe/k0R89YXYDhUYaUP4itNB8Lq3iZn8q0octtnYvxot0jFRgFKYA3brQ/C17L4DAkxJtVALZtU90RIVL6HhD541a8C0IUkTGEYUTT44pCRy6Px2NPqUbdL+2JJENclfVxU27oya/vHweSzBe330T78SxyIRiHSrO0+fXRtmWyUWNrDaNaY1Z1YIfbjf1HHYI9PQ1lycHzUYjqnmUkFP91K5J0jmSgnFfs+spHZgVeV2ZqYXiww==
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=FW6VDq8qVP3JSTF1IO/J6nwXb95n8jSDYzGdx2vbCSs=; b=UtAS2OiXQIRW8j9R2u3aVHVfuhoMHTIYdYKXCIRkI9jW7lrm7lGramHj4dO60E/X4QuajKJwfVH6EInk/bym3EnDs7Yn6ttRxtxerqg9mahAP89vgFd+VyWDK6fU+AgjSE/RtxT26lDg7sEfPp4PvF0YbXX4mkRp5DvoVDWzN98=
Received: from CY4PR11MB1541.namprd11.prod.outlook.com (10.172.68.150) by CY4PR11MB1479.namprd11.prod.outlook.com (10.172.66.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16; Wed, 9 Oct 2019 14:22:42 +0000
Received: from CY4PR11MB1541.namprd11.prod.outlook.com ([fe80::6081:81d9:b59c:fb19]) by CY4PR11MB1541.namprd11.prod.outlook.com ([fe80::6081:81d9:b59c:fb19%10]) with mapi id 15.20.2305.023; Wed, 9 Oct 2019 14:22:42 +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/AgCmh2gCAJMMMMA==
Date: Wed, 9 Oct 2019 14:22:41 +0000
Message-ID: <CY4PR11MB15415121B84FA55CB4F0B8E6C1950@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>
In-Reply-To: <CAE+itjfBRL0S7=N2kzHOsHDrcPL-OANw3tZfDiguXw0SupBLzw@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: [72.163.220.10]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 396cc49d-89c4-479e-a802-08d74cc4255e
x-ms-traffictypediagnostic: CY4PR11MB1479:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <CY4PR11MB14796F5918017B22436B0DC0C1950@CY4PR11MB1479.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 018577E36E
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(39860400002)(366004)(136003)(396003)(376002)(13464003)(189003)(199004)(52284002)(14454004)(966005)(606006)(486006)(25786009)(11346002)(3846002)(6116002)(478600001)(476003)(446003)(53546011)(6506007)(102836004)(66446008)(64756008)(66556008)(66476007)(66946007)(99286004)(76116006)(76176011)(186003)(2906002)(7696005)(26005)(7736002)(33656002)(74316002)(790700001)(6916009)(9686003)(54896002)(6306002)(316002)(236005)(55016002)(229853002)(6436002)(54906003)(8936002)(8676002)(81166006)(81156014)(9326002)(7520500002)(256004)(71190400001)(71200400001)(6246003)(86362001)(4326008)(66066001)(52536014)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR11MB1479; 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: 3QYmEmmU+Br34m5EwYCMUipo68xhyf0f0ynOKALg9o4PTYAGdv2ludp/OPxOFxGVdocjF/nLybpjqeF9oOcZrhsIyeAPy+LagxU4agONRPI/Bx9mNi1E7QqgnMEE3u99dIPYj3fJbKFlyJENNsfp7DaQGTXudtKKacJdKwVoSDp2sXOwh1HOc9DQbRBKaSGcs9GUdnAZT7zz29v8FCigeYJiIQ/wWk0QFu5hhgi74BiF5pNtEL+pcER/BL49fIErDZb5W3tBZNMe7nNU/HdOzFuEozsZOQpYu6ujXgf/82b1nJtAap760qGxlckt6D4tcb36YeXw124JWyDHlDz1DHC3rl8aN080/5SN3zVW1XO0OOiDIiUpIG2WziaIwubSYv4MgSFIBo3dSG8g17mF+1I09NvFPFuODK4j3JBKTWrQlKeKhc3He3NWNsLzJ2pL0r9LHalDh1f2grylefSoRw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CY4PR11MB15415121B84FA55CB4F0B8E6C1950CY4PR11MB1541namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 396cc49d-89c4-479e-a802-08d74cc4255e
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2019 14:22:41.8206 (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: FFSkDkFijavy+y3rX1hGXOdhyn6965WW3+Cwd2hDVMVDMQCiPKsCcefaDg9vUnUY+PW+D8EU3g5d3XqZtP3Reg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB1479
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.21, xch-aln-011.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Q_xJvtDXNPWN_9uGmSh_dp0yISY>
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: Wed, 09 Oct 2019 14:22:49 -0000

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.

Thanks,
Ketan

From: Nandan Saha <nandan@arista.com>
Sent: 16 September 2019 10:11
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,
    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