Re: [Idr] Section 4.7 of RFC#7752 bis

Balaji Rajagopalan <balajir@juniper.net> Mon, 02 December 2019 09:34 UTC

Return-Path: <balajir@juniper.net>
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 69B841200CC for <idr@ietfa.amsl.com>; Mon, 2 Dec 2019 01:34:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=juniper.net header.b=vzqg/NZZ; dkim=pass (1024-bit key) header.d=juniper.net header.b=NDhoVvXl
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 zD7Jc6VaN2d5 for <idr@ietfa.amsl.com>; Mon, 2 Dec 2019 01:34:41 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ED28120044 for <idr@ietf.org>; Mon, 2 Dec 2019 01:34:41 -0800 (PST)
Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xB29WQ2u013876; Mon, 2 Dec 2019 01:34:38 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=jY/hao3tNVjLFyfdhvE/KshbVrh0MZkooizukWhXvy4=; b=vzqg/NZZibRKuHB7pVLrK2kaHaFHvzPtbJtBZc/5LnWkFRgmRWkVG/N7cEcK32ccJ6ck rggnTci6FZ1KwtNyPZEi/5+7lbJ9qqnkpitZui8+lyOu24lXB8xoGlu9X9MU/k8YKG5i QSnp2oMgvndRVR+b1FTBJ4iB+r+uVhJ41YtRRPn+rppMEa9G/XCp3eZm/9xzwdKWwar1 5hSAJHScfEKgUQZjQElJggdUpG5bJeDfH61tWDeWcum2/oCJAeeGoAtvzHzNjuiKPTUe LQQ68LXnXaC91x+NcB+QFnYS3Z+p0BYrZn20GwMA6riRB/208FPzNlMMqx3Akq3DBMdB zA==
Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp2054.outbound.protection.outlook.com [104.47.40.54]) by mx0b-00273201.pphosted.com with ESMTP id 2wkq7jtca4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 02 Dec 2019 01:34:38 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m+/31Gso1L4DnzYd4bnX34hpc28WXSULxw6bL23xcJvQf63nUbYR6TBQ0d6P8CqjfScXJSdRhQPgCEvZ4F/m37kRHKrxGsSq9RQUhTvoqGXoJEc6Psg8fPURXjSL2GeCP9D7mdPaAEdJTyFehiFhb8RJtyv17PD+3C4QYmFhBDbkXo7FGMbioItwFi+Jp7NIJukuX4MJe9VCo08456albmqnJ6XEBhijPRU0TjtNXFklIm0ygcbGfQB8Bor3cecNfQ2t3Kx+S7y7MUO91wMgOJPQRij95NwAHNKrTEVA3svnCF8KDDTOQXr4rdPdYxtKay0RyX01+fahdo4wKAbuAw==
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=jY/hao3tNVjLFyfdhvE/KshbVrh0MZkooizukWhXvy4=; b=EC2+PsN+jXwytkD5j+2Mzy0zabZUxVPuCaKpLz5IUBdoL1tt+39wOHf3QsEcZHVwxvBF7JbaedFw2cvwQwHu/I1D+EeiFNwKrpZ5T7hLl22MjBicrOwVPowmFQEd3M3iEXD53EM36j2FuNN/smnvb3uPf0Jx6M8JM5l0afQqLEvIivPxXzjmcRR0/8W+6EuHB/JkLm3GLJ7GRN28wLCr1odhJpEGznVaKdtNcb0sUF1t9pRghX+wEZHI+N8+OboUWZkL2Mk3w2G40jPUJgSNHoQyVRkJYqLlDmAI1rFoCrFH0XtGnuDndp1tepedtpgBBv09guhDa0+PE4Ml824hbw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jY/hao3tNVjLFyfdhvE/KshbVrh0MZkooizukWhXvy4=; b=NDhoVvXlS4Oo8qqUXT4Ck5NI0vxmW5Hnl3MXhG76+LrJZu6DJxv6aE8TZ8a7YUq3kJdK8wDLJY9UW1FSrKvYfDZpQcY4+ZkvZagd/RJHXkeylUgH8qsDNMxK2BcFiKrDnMBF7idSWAGkYnjhqciNV/OaaAmTOeEiVbiHv/oNODY=
Received: from MN2PR05MB6189.namprd05.prod.outlook.com (20.178.243.224) by MN2PR05MB6512.namprd05.prod.outlook.com (20.178.247.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.4; Mon, 2 Dec 2019 09:34:35 +0000
Received: from MN2PR05MB6189.namprd05.prod.outlook.com ([fe80::5cc4:6dae:a6ee:1617]) by MN2PR05MB6189.namprd05.prod.outlook.com ([fe80::5cc4:6dae:a6ee:1617%4]) with mapi id 15.20.2516.003; Mon, 2 Dec 2019 09:34:35 +0000
From: Balaji Rajagopalan <balajir@juniper.net>
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
CC: 'idr wg' <idr@ietf.org>
Thread-Topic: Section 4.7 of RFC#7752 bis
Thread-Index: AQHVk7ORQ+PQmhOzhkmQg/whWt4afKeBHQiAgArpXgD//7znsIATc8wAgAKOCZCABVcTAA==
Date: Mon, 2 Dec 2019 09:34:35 +0000
Message-ID: <EF21EAB6-4653-44A9-BA85-39F08A1B4C00@juniper.net>
References: <C5AE54F0-44F3-408C-875E-8B0D765B24C9@juniper.net> <CY4PR11MB154101501CB5568C8539FF02C17B0@CY4PR11MB1541.namprd11.prod.outlook.com> <35A7D8D9-E256-4392-A5DD-A5C1ADC537CB@juniper.net> <CY4PR11MB15411E90EC6A804F6B620491C1700@CY4PR11MB1541.namprd11.prod.outlook.com> <52A4B9BF-A533-41BD-BC50-F97A3A00002A@juniper.net> <MWHPR11MB1600214BD5DE6A1CFAF3B91CC1460@MWHPR11MB1600.namprd11.prod.outlook.com>
In-Reply-To: <MWHPR11MB1600214BD5DE6A1CFAF3B91CC1460@MWHPR11MB1600.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_Enabled=true; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_Name=Juniper Business Use Only; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_Enabled=true; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_ContentBits=0; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_Method=Standard; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_ActionId=55d4724b-cdd4-46e8-b4ca-0000a8e6bc06; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_SetDate=2019-11-05T07:22:02Z;
user-agent: Microsoft-MacOutlook/10.1f.0.191110
x-originating-ip: [116.197.184.15]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 0299fae2-e65b-4614-537a-08d7770ad7f4
x-ms-traffictypediagnostic: MN2PR05MB6512:
x-microsoft-antispam-prvs: <MN2PR05MB651248302B61073CD12990A9AB430@MN2PR05MB6512.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0239D46DB6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(376002)(346002)(396003)(366004)(39860400002)(189003)(199004)(186003)(86362001)(478600001)(229853002)(6436002)(6916009)(14454004)(6246003)(71190400001)(71200400001)(33656002)(6512007)(54896002)(6306002)(5660300002)(6486002)(606006)(76176011)(66946007)(236005)(66476007)(66556008)(66446008)(64756008)(102836004)(36756003)(76116006)(91956017)(6506007)(53546011)(81166006)(25786009)(7736002)(81156014)(8936002)(2906002)(58126008)(561944003)(316002)(9326002)(14444005)(2616005)(4326008)(446003)(11346002)(256004)(66066001)(8676002)(26005)(3846002)(6116002)(99286004); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR05MB6512; H:MN2PR05MB6189.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: k18X6Un6Wn1wckVdALqwHdNDw09DrhqumgmaqOXNs3rflqO6KmSV8/Qq1QLd8Ah+j/A9T4wuhlUVXyCK7y5Hzcphp43tw1UmsvkJHwsqwqTPQ01E9YHuufuFV6/jQJlhjjn+a8deQGEPBRiO5z4PdO8DYKSS/7pL50vHEYcVY9kXBUYPvT1FSyaHRH+zLXzU87mQ2w7N3c8hzxL65GbTFh7gvyr6Sxag5yBhPPQ5e9VbkRFXXHhXXzLQabqlb7/FEp9U2XHbILSvlMy+4zJfstwx+5XVRU5h1JReokxf1SoLYR64TGQMY1pKQe6tiTcE+0hVhQVNzVDLk4RtDJMk2r9TZo10W8d8YfVsqBzNKgujPgSiIr+Ltx6ahljZZK07Ypm6LCWqOrZz/juvJTMsn1QdyBcyrj9Y8YZzlEg+hQ49j+34JiTkH4dQ8JiLdEOiCE8RDXK2j8+vNP8v8NIrC2Rz54rLIJ0q7qnsdCSLzOc=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_EF21EAB6465344A9BA8539F08A1B4C00junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 0299fae2-e65b-4614-537a-08d7770ad7f4
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2019 09:34:35.1027 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: FA/0//GzF9DmVpvUSZ/t5geUFJOwUwJV0PVfEAls4shZc516ro2NxUSpukM76AMKs2ZskK/NOmwIN4EQ5XEwrg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6512
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-02_01:2019-11-29,2019-12-02 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 adultscore=0 suspectscore=0 mlxlogscore=999 phishscore=0 lowpriorityscore=0 bulkscore=0 mlxscore=0 impostorscore=0 malwarescore=0 clxscore=1015 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912020087
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/qDtzFusvlEZbLBxUnOF0kcpk_u4>
Subject: Re: [Idr] Section 4.7 of RFC#7752 bis
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: Mon, 02 Dec 2019 09:34:44 -0000

Hi Ketan,

>> A BGP-LS Consumer MAY filter stale entries of unreachable nodes by treating each Producer’s view of the topology as a separate partition.
>>[KT] This is not sufficient and actually the consumer would have to run SPT computation using each Producer’s view to determine the nodes that are unreachable in its view? If your implementation is actually doing this, then it helps if you could clarify.

Yes, the consumer needs to run SPF rooted at each Producer to determine unreachable nodes.

No, I’m not aware of any implementation that does this. But, the model is akin to IGP in that propagator sends the information unmodified, leaving semantic processing to the recipient.

>>[KT] Could you please clarify what “other well-known solutions” are being referred to apart from add-path here? If the solution is add-path then I would skip the above sentence or merge it with the next one.

This text refers to the solutions listed below it. Yes, I think we can skip/merge that part.

--
Balaji Rajagopalan

From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>;
Date: Friday, 29 November 2019 at 11:13 AM
To: Balaji Rajagopalan <balajir@juniper.net>;
Cc: 'idr wg' <idr@ietf.org>;
Subject: RE: Section 4.7 of RFC#7752 bis

Hi Balaji,

Please check inline below.

From: Balaji Rajagopalan <balajir@juniper.net>;
Sent: 27 November 2019 14:31
To: Ketan Talaulikar (ketant) <ketant@cisco.com>;
Cc: 'idr wg' <idr@ietf.org>;
Subject: Re: Section 4.7 of RFC#7752 bis

Hi Ketan,

Sorry for the delayed response.

Yes, I’m okay with a ‘SHOULD’ in place of ‘MUST’. I had a brief chat with John Scudder, and he reminded me that a ‘SHOULD’ condition must be accompanied by text that clearly explains under what conditions an implementation is not required to follow the ‘SHOULD’ condition.
[KT] Agree.

John & I came up with the following amended text for review:

There are two strategies that can be used to solve the above problem: producer-controlled & consumer-controlled.

  1.  A BGP-LS Producer SHOULD withdraw all link-state objects advertised by it in BGP when the node that originated its corresponding LSP/LSAs is determined to have become unreachable in the IGP, unless the Consumer is interested in receiving all the entries. If the Producer does so, it MUST re-advertise those link-state objects only after that node becomes reachable again in the IGP domain.
[KT] We can wordsmith this but I agree.

  1.  A BGP-LS Consumer MAY filter stale entries of unreachable nodes by treating each Producer’s view of the topology as a separate partition.
[KT] This is not sufficient and actually the consumer would have to run SPT computation using each Producer’s view to determine the nodes that are unreachable in its view? If your implementation is actually doing this, then it helps if you could clarify.
In order to perform this step, the consumer needs to have visibility into each Producer’s entries.

When Route Reflector (RR) is in use, as depicted in the diagram, the route selection procedure in the RR may conceal all but one entry.  This is similar to other issues that  arise when route reflection is used, and the other well-known solutions to  such problems MAY be applied instead of option-1.
[KT] Could you please clarify what “other well-known solutions” are being referred to apart from add-path here? If the solution is add-path then I would skip the above sentence or merge it with the next one.
The route reflector can refrain from hiding data, by using add-path [ref] to advertise all the routes. The consumer would have to use ‘Originator ID’ attribute to identify the Producer.

Another option is to operationally refrain from  using route reflection for this application: if the consumer in the above example peered directly with R2 and R3, the consumer would have full access to each partition’s view.
[KT] We can wordsmith this but I think it makes sense to have this as an option for the 2nd approach.

Thanks,
Ketan

--
Balaji Rajagopalan


From: "Ketan Talaulikar (ketant)" <ketant@cisco.com<mailto:ketant@cisco.com>>
Date: Friday, 15 November 2019 at 11:28 AM
To: Balaji Rajagopalan <balajir@juniper.net<mailto:balajir@juniper.net>>
Cc: 'idr wg' <idr@ietf.org<mailto:idr@ietf.org>>
Subject: RE: Section 4.7 of RFC#7752 bis

Hi Balaji,

I have personally no issue changing the MUST to SHOULD in the following text so that using the solution you propose for the very specific use-case that you have in mind is possible without being non-compliant to the specification.

   A BGP-LS Producer MUST withdraw all link-state objects advertised by
   it in BGP when the node that originated its corresponding LSP/LSAs is
   determined to have become unreachable in the IGP and it MUST re-
   advertise those link-state objects only after that node becomes
   reachable again in the IGP domain.

Would that completely address your concerns?

However, if you also wish to add this other option then we ought to at least explain that mechanism properly to enable review by the WG. When you say “advertise the links from both the partitions using ADD-PATH”, it is not really intuitive for reader of the document to understand this and its implications in the BGP-LS context.

In Montreal, I put together some slides<https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/105/materials/slides-105-idr-sessa-draft-ketant-idr-rfc7752bis-01__;!8WoA6RjC81c!Rxubt6nAMCIrzyBGtaPm7pq6fSdGiKyGY8o6Tr99-My6SdHIZyvv7Fwa1G29-ov9$> with your help to try and explain your proposal (solution B) and still it was difficult for many experts in the room to understand the need and motivation for it – the minutes<https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/105/materials/minutes-105-idr-01.htm__;!8WoA6RjC81c!Rxubt6nAMCIrzyBGtaPm7pq6fSdGiKyGY8o6Tr99-My6SdHIZyvv7Fwa1ERc30cG$> and the recording<https://urldefense.com/v3/__https:/www.youtube.com/watch?v=7tgD-hPPIhI__;!8WoA6RjC81c!Rxubt6nAMCIrzyBGtaPm7pq6fSdGiKyGY8o6Tr99-My6SdHIZyvv7Fwa1B2kSs6p$> are available to refresh our collective memory.

In full disclosure, I personally find your proposed solution B very complex with little or no benefit – even though, IIRC, I did not express that opinion during the session in order to not influence. I do agree though that you should have the flexibility to implement your solution for the use-cases you have in mind while the draft tries to capture the simpler and consensus solution for most of the broad use-cases.

So if you wish to still put forward your alternate mechanism, then please provide a good text that enables review by the WG. However, if you are happy with just the above text change that I’ve proposed then we are good and this can be posted in the next update for the draft.

Thanks,
Ketan

From: Balaji Rajagopalan <balajir@juniper.net<mailto:balajir@juniper.net>>
Sent: 15 November 2019 09:28
To: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>
Cc: 'idr wg' <idr@ietf.org<mailto:idr@ietf.org>>
Subject: Re: Section 4.7 of RFC#7752 bis

Hi Ketan,

>> So, my suggestion would be the following:
>>Clearly describe the problem, as the current draft does
>>Describe both the solutions (ADD-PATH & the current text), and make them both optional behaviours available to an originator
>> [KT] Could you propose the text to describe the ADD-PATH solution? We can get the WG feedback for its inclusion as another alternative in the document.

Please see below suggested replacement text for the last paragraph of section 4.7. Please feel free to massage the text.

A BGP-LS Producer has two ways to cope with the above problem:

  *   Do not advertise the links of unreachable nodes
  *   Advertise the links from both the partitions using ADD-PATH, so the consumer has enough information to identify the stale entries.


--
Balaji Rajagopalan