Re: [Idr] [draft-ietf-idr-rfc7752bis] Question on explicit withdrawal of BGP-LS NLRI

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Fri, 15 November 2019 09:27 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 2E49D12016E; Fri, 15 Nov 2019 01:27:52 -0800 (PST)
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, 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=Kuexp5B6; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=p5IzJTbR
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 8rniUPvr3swT; Fri, 15 Nov 2019 01:27:50 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BC9B120168; Fri, 15 Nov 2019 01:27:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3408; q=dns/txt; s=iport; t=1573810070; x=1575019670; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jNTymU7FKKvWLUjUIOG+6q5zd9asStP2pzU6yZnxouA=; b=Kuexp5B67uA1jZllrnMSAhSILq4S5P7E80IZA14MrHEc6je0sbYJV0z4 RqYB1xYoQ6hkVUIPLn8M/EXzB14HLnx0S3RmX1Ef5bKg1Y9G62XWeQy/b Q1Ip6R1Zrp2M4KQjMCUZNLV1heDzkED+FI4Df0/g/RZg4K5l9IN2UUQ92 g=;
IronPort-PHdr: 9a23:SpScthQyguvwQ+dWgPblJbbaVtpsv++ubAcI9poqja5Pea2//pPkeVbS/uhpkESUDNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH15g640NmhA4RsuMCEn1NvnvOi83AM1ESHdu/mqwNg5eH8OtL1A=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BKAAB/bs5d/5hdJa1lHAEBAQEBBwEBEQEEBAEBgWoHAQELAYFKUAWBRCAECyqEKYNGA4RahhqCXpgAgS6BJANUCQEBAQwBAS0CAQGEQAIXggkkNAkOAgMLAQEEAQEBAgEFBG2FNwyFUQEBAQEDEhERDAEBNwELBAIBCBEEAQEDAiYCAgIwFQgIAgQBDQUIGoVHAy4BpF8CgTiIYHWBMoJ+AQEFhRYYghcJgQ4oAYwUGIFAP4ERRoJMPoRHFYJ5MoIsjSSCb48Ijh5uCoIqjD6JKoI+h2eOBIFkjkiBQZhGAgQCBAUCDgEBBYFSOYFYcBWDJ1ARFJEag3OKU3SBKJBDAQE
X-IronPort-AV: E=Sophos;i="5.68,307,1569283200"; d="scan'208";a="661983749"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Nov 2019 09:27:48 +0000
Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id xAF9Rml1010225 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 15 Nov 2019 09:27:48 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 15 Nov 2019 03:27:48 -0600
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 15 Nov 2019 04:27:47 -0500
Received: from NAM02-SN1-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.1473.3 via Frontend Transport; Fri, 15 Nov 2019 04:27:47 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PIa7m6E2IqOFPqh96Oh+yt7uBrMCXcjdNjH7T9TQfQm6xbRjMoriNQefiID7AXNjv7tILjLLG/Mqo2phVkcq+60R/uN/j4b7hccJsxugwJknqtey30p+2bjJ87Y/KPNzsojncOKLge6QswZAIOcDkHW9hpw/lkdajZZXDk5fvpUY8ECL7pn7o4ICmE9Z5n8ainYCcXrdJDfxm6o2uO0fTmQzTY9lTeIpwnl+eQykVDQ4UWhzEficbgYuKdD0S0JEsYqGi1A/0UI9eZODU2y0BadlzY10Eq03P6P21Zp6jsVK7rQ7fM+Rc63M6VevQkgvMTA75CsIKR1da/+upas1gw==
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=jNTymU7FKKvWLUjUIOG+6q5zd9asStP2pzU6yZnxouA=; b=UcxTCdHuqCns4A4arJel1GPzd9HdUBSJmhQAXN4lCxdULIMio45t3D2JbKO0MziiB4CYXIualfxGZEJ8h68L1AgtVvlL9N+SWXuasSQ5H+fjDcRjT5TY96u1/QcItxgzo7CC7KHO+gVtevw6FSufYTeCnWYGEfnqQmIC1G9E3HtDriTBrBVtzv+JNVwSgU94F8wJAFDLFD1pFSqtZp6/jjfOskuz6OtSiIqC0mh8WnDZOXtttvcpxfqPxDj1XvWEmQ2OtZq19IaY8TuhUschJWfvo8WIlBbC789RYUkxdnXKkjByLwzbciF+M2ZfV23Z1QDPMCG8BOKbt4Y2xXLNhg==
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=jNTymU7FKKvWLUjUIOG+6q5zd9asStP2pzU6yZnxouA=; b=p5IzJTbR4J9MpVc2TJOe6IkSxpg3fA1NWugOftmjwWo72v46UfmZYGuMSp7YOvF0oLyujLsFZRVzz2/f3W4F/bEO313egoa9cYZGKgWJmVsApum+ExXN4dXatj10jOsvs2KwErWJnvmTzOo4ebLPNkSLQX/qjmzDpr1CN2ylZqs=
Received: from MWHPR11MB1552.namprd11.prod.outlook.com (10.172.55.18) by MWHPR11MB1471.namprd11.prod.outlook.com (10.172.53.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.23; Fri, 15 Nov 2019 09:27:45 +0000
Received: from MWHPR11MB1552.namprd11.prod.outlook.com ([fe80::b5fb:4e81:5e8:55c2]) by MWHPR11MB1552.namprd11.prod.outlook.com ([fe80::b5fb:4e81:5e8:55c2%12]) with mapi id 15.20.2451.024; Fri, 15 Nov 2019 09:27:45 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Nandan Saha <nandan@arista.com>, "draft-ietf-idr-rfc7752bis@ietf.org" <draft-ietf-idr-rfc7752bis@ietf.org>, "idr@ietf.org" <idr@ietf.org>
CC: Prakash Badrinarayanan <prakash@arista.com>
Thread-Topic: [draft-ietf-idr-rfc7752bis] Question on explicit withdrawal of BGP-LS NLRI
Thread-Index: AQHVm5Jfwj0RqHPzXka+o/MmPLTddKeL9Mwg
Date: Fri, 15 Nov 2019 09:27:44 +0000
Message-ID: <MWHPR11MB1552FB3F517C66D05B5E7037C1700@MWHPR11MB1552.namprd11.prod.outlook.com>
References: <CAE+itjeAoU9tXxoZg2sOYYOA94pCrRviUGeoQ43jvTzQhhwOnQ@mail.gmail.com>
In-Reply-To: <CAE+itjeAoU9tXxoZg2sOYYOA94pCrRviUGeoQ43jvTzQhhwOnQ@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: [2001:420:c0e0:1005::87]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 96afe5cb-6606-414a-5019-08d769ae1265
x-ms-traffictypediagnostic: MWHPR11MB1471:
x-microsoft-antispam-prvs: <MWHPR11MB1471C626499357D35B9500ACC1700@MWHPR11MB1471.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02229A4115
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(396003)(376002)(39860400002)(346002)(199004)(189003)(13464003)(74316002)(7736002)(99286004)(66574012)(316002)(5660300002)(6246003)(110136005)(4326008)(71190400001)(71200400001)(256004)(229853002)(476003)(11346002)(52536014)(446003)(33656002)(186003)(46003)(14444005)(102836004)(486006)(6436002)(66946007)(66446008)(64756008)(66556008)(66476007)(9686003)(7696005)(8936002)(55016002)(81166006)(8676002)(2501003)(76176011)(2906002)(6506007)(53546011)(81156014)(6116002)(2201001)(76116006)(25786009)(478600001)(86362001)(14454004)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1471; H:MWHPR11MB1552.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: meb0KKtWkjzZyjLi7p2j31SnRVkRJGve3LYVOhgyhwp6b0YckUPZgv2arGuITZOhueXrLN45kCKEWYpqXgXc9zug9GxJAmYxn4x4DAfiDQ8lZ7rNjydfuNXLdo2Lqz3ReHRvPDF5DEhFIgl33im64+P6qsyZF7P13KoC9Ky9L+cnm1WwcItIyef7BVXVSVwYZEhKR461LXxGPq2VW8xKSd2V+er3lI0wouGDwibcLFOGb/FPyloqXsAtvDW2EO+ev5BCuPuMsy/3CXt9nb1qKJL2ck4Q5QT0i6a3ar48EIA+Eb0tuswVXxnMSCyB5N4/c0T8HH2MWg4SsUdFfHkMlG0QYDNMTonfwfU0dfENcPzJPRVzeiOut9WfrxG0S6f9ZZUWCPdMKsURC1k09iusAEV/brvOyWdPHnoVWDMbcplkBfO28ouNonbhOd2Au4jI
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 96afe5cb-6606-414a-5019-08d769ae1265
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2019 09:27:44.7891 (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: wahJ4MuXUIpIG071bjWe2+WMTsJycGuW4T3qCqiQM0prRjgINuazFFjN4Ej+r19lkr0OB1gipQF8j2LAsgjDzA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1471
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.24, xch-aln-014.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/1SlyYLeQ-EHg4b6hrHLwyUXPDM4>
Subject: Re: [Idr] [draft-ietf-idr-rfc7752bis] Question on explicit withdrawal of BGP-LS NLRI
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, 15 Nov 2019 09:27:52 -0000

Hi Nandan,

Please check inline below.

-----Original Message-----
From: Nandan Saha <nandan@arista.com> 
Sent: 15 November 2019 14:25
To: draft-ietf-idr-rfc7752bis@ietf.org; idr@ietf.org
Cc: Prakash Badrinarayanan <prakash@arista.com>; Ketan Talaulikar (ketant) <ketant@cisco.com>
Subject: [draft-ietf-idr-rfc7752bis] Question on explicit withdrawal of BGP-LS NLRI

Hi folks,

 I'm trying to understand what the following text is actually mandating:
>>>>
 When adding, removing or modifying a TLV/sub-TLV from a Link-State  NLRI, the BGP-LS Producer MUST withdraw the old NLRI by including it in the MP_UNREACH_NLRI.  Not doing so can result in duplicate and in- consistent link-state objects hanging around in the BGP-LS table <<<<

Is it simply about ensuring that the previous incarnation of the NLRI is withdrawn
[KT] Yes
  (or)
is it also mandating some ordering requirements between when the old incarnation is withdrawn and the new one advertised.
[KT] No

For example, if there's a link nlri say NLRI1 = {  local node descriptor {
   asn = 100
   igp router ID = 1111.1111.1111
 }
 remote node descriptor {
   asn = 100
   igp router ID = 2222.2222.2222
 }
 link descriptor {
   ipv4 Intf address = 1.1.1.1
   ipv4 neighbor address = 1.1.1.2
}
}

Which say subsequently changes such that NLR12 = {  local node descriptor {
   asn = 100
   igp router ID = 1111.1111.1111
 }
 remote node descriptor {
   asn = 100
   igp router ID = 2222.2222.2222
 }
 link descriptor {
   ipv4 Intf address = 4.4.4.4
   ipv4 neighbor address = 4.4.4.5
 }
}

Note that the interface address changed above in NLRI2

In this case, is it sufficient to ensure that a MP_REACH_NLRI is sent with NLRI1 and an MP_UNREACH_NLRI is sent with NLRI1 in _any_ order or is that text mandating something stricter?
[KT] The text does not talk about order - just about sending MP_UNREACH_NLRI for the old incarnation.

Do both MP_REACH_NLRI=NLRI2 and MP_UNREACH_NLRI=NLRI1 need to be sent in the same UPDATE message or the MP_UNREACH_NLRI has to be sent before the MP_REACH_NLRI if sent in different UPDATE messages?
[KT] They are separate NLRIs and how to send is implementation aspect. Regardless of how one sends, the receiver would need to handle updates in any order. Note that there may be an RR in the propagation path and so one cannot assume whether the two NLRIs are packed in the same or different update msg.

Thanks,
Ketan

Thanks,
Nandan