Re: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt

Aijun Wang <wangaijun@tsinghua.org.cn> Wed, 05 August 2020 14:04 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
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 306C23A0898 for <idr@ietfa.amsl.com>; Wed, 5 Aug 2020 07:04:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 id8MgBTNkVzJ for <idr@ietfa.amsl.com>; Wed, 5 Aug 2020 07:04:24 -0700 (PDT)
Received: from mail-m127101.qiye.163.com (mail-m127101.qiye.163.com [115.236.127.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 425AD3A0870 for <idr@ietf.org>; Wed, 5 Aug 2020 07:04:21 -0700 (PDT)
Received: from [192.168.124.2] (unknown [111.194.51.107]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id C818E487D3; Wed, 5 Aug 2020 22:04:15 +0800 (CST)
Content-Type: multipart/alternative; boundary=Apple-Mail-4F3FA653-B002-4DC0-8A9D-283E2F7E769E
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Wed, 5 Aug 2020 22:04:15 +0800
Message-Id: <60324DD5-A8A5-4F96-9F62-DB5535C435CF@tsinghua.org.cn>
References: <D2AB2BF9-0DE7-4B65-A585-C4FB6407FEA7@cisco.com>
Cc: Robert Raszuk <robert@raszuk.net>, Keyur Patel <keyur@arrcus.com>, "wangw36@chinatelecom.cn" <wangw36@chinatelecom.cn>, idr <idr@ietf.org>
In-Reply-To: <D2AB2BF9-0DE7-4B65-A585-C4FB6407FEA7@cisco.com>
To: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
X-Mailer: iPhone Mail (17F80)
X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZHkoeGBpITRlCH0sYVkpOQk1NSE1JTk1LSUJVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0hKTFVKS0tZBg++
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Mwg6Cgw4Hz8eMUsZIU0RKzwi PiFPCRNVSlVKTkJNTUhNSU5NTkNLVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKSkpVSkJPVU5KVUpLTFlXWQgBWUFMSkhMQzcG
X-HM-Tid: 0a73beefd64f9865kuuuc818e487d3
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/OEOSK3QWIkXWQjkgu8jmVZm2Uuo>
Subject: Re: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt
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, 05 Aug 2020 14:04:28 -0000

Hi, Rajiv:
If RD is allocated as per VRF per PE, the overflow VRF on one PE will find the source RD(also source VRF on source PE) that leads to the overflow. 
Only the routes that carry this specified RD will be suppressed. It will not influence other VRFs on the overflow PE, because there is no other VRF sourcing the routes that carry the same RD.
If not, there will be VPN prefix collision.

If the RD is allocated as per VRF only, that is to say, same VRF( corresponding to same VPN/Customer) on different PE use the same RD, the filter entry should also consider the source PE.

We have updated the encoding of RD-ORF message in the latest version. Section 5 that you referenced should also be updated.
Thanks for your review and comments.

Aijun Wang
China Telecom

> On Aug 5, 2020, at 19:54, Rajiv Asati (rajiva) <rajiva@cisco.com> wrote:
> 
> 
> Aijun,
> 
> Pls see inline , 
> 
>> [WAJ] Route Import is based on RTs, but different VRFs on one PE will use different RDs(and also different import RTs). Then filter based on RD will not influence the route import in another VRF, especially within the same PE.
> 
> 
> How so? Based on the excerpt from section 5, it seems clear that  RD-ORF would cause an outage for all VRFs that import one or more routes matching the RD. 
> 
> //
> 
> Before sending a VPN route (the RD is equal to RD1) toward PE1, PE2
>    will check its Adj-RIB-out and find the RD-ORF entry prevent it from
>    sending VPN route which carries RD1 to RR2.  Then, PE2 will stop
>    sending that VPN route.
> //
> 
> 
> Cheers,
> Rajiv  
> 
> 
>>> On Aug 5, 2020, at 3:48 AM, Aijun Wang <wangaijun@tsinghua.org.cn> wrote:
>>> 
>> 
>> Hi, Robert:
>>  
>> Thanks for your comments.  Please see the detail responses inline.
>>  
>> From: Robert Raszuk [mailto:robert@raszuk.net] 
>> Sent: Wednesday, August 5, 2020 2:55 PM
>> To: Aijun Wang <wangaijun@tsinghua.org.cn>
>> Cc: Keyur Patel <keyur@arrcus.com>om>; idr <idr@ietf.org>rg>; wangw36@chinatelecom.cn
>> Subject: Re: [Idr][Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt
>>  
>> Hello Aijun,
>>  
>> 【Robert】: there was a number of technical problems sent to the list. None of these were addressed. This is not the right way to filter VPN
>> 【A-WAJ】:Would you like to point out which technical problem isn’t addressed yet?  We have also compared the existing solutions and their limitations in the draft and at the presentation.
>> As you know VPNs use different scheme of RD allocations. Most common would be to import RDs with local rewrite. So I know you realize that and your intention is to signal such RD to RRs or other PEs from the pre imported routes. So far so good. 
>> Now realize that on a given PE there is few VRFs which need to import given RD. Import is based on RTs. Therefor not all target VRFs may import same subset of routes originally carrying given RD. One VRF can import 5 routes, the other 10 and yet one more 10000. Let's assume for now that that last VRF "overflows" and decided to trigger RD-ORF. 
>> That means that PE signals this to RR and RR stops sending all such routes to given PE. That effectively means that even those first two VRFs which are fine as they just import subset of routes suffer unreachability as those routes are simply no longer arriving at the PE. 
>> [WAJ] Route Import is based on RTs, but different VRFs on one PE will use different RDs(and also different import RTs). Then filter based on RD will not influence the route import in another VRF, especially within the same PE.
>>  
>> For me this is showstopper - and pretty fatal one to use RD for filtering. We do import based on RTs and filtering should also be done based on the RTs. 
>> [WAJ] RT can’t be uniquely to identify one specified VPN.
>> My other serious concern is that end customer will in no one be notified about such RD-ORF filtering ... - that is frankly not acceptable to me or to any L3VPN or L2VPN customer. As comparison when you use prefix limit on the PE-CE customer's session goes down hence customer is alerted about the problem. 
>> See worst "solutions" are those which may cause silent failures. We should avoid those at all cost. 
>> [WAJ] The RD-ORF message is initiated from the overflow PE.  The RR or the source of VPN overflow act based on the instruction from the applier. Then this is not silent failures.
>>  
>> Last this is measure to protect SP resources (PEs). Let me observe that this topic came up in early 2000 and it was commonly agreed that the best we can offer is protect the network from any customer injecting more then in the customer <--> SP SLAs. 
>> Beyond that SP's infra must keep good monitoring of PE resources instead of waiting for disaster to happen and building parachutes. 
>> [WAJ] RD-ORF just want to keep the disaster as small as possible, based on the parachutes J
>>  
>> Kind regards,
>> R.
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>> On Wed, Aug 5, 2020 at 4:34 AM Aijun Wang <wangaijun@tsinghua.org.cn> wrote:
>> Hi, Keyur, Praveen and Robert:
>>  
>> Thanks for your comments on this draft during the IETF 108 meeting.  
>> Below are responses for your questions, please review them to see whether they resolve your concerns:
>>  
>> 【Q-Praveen】: When PE1 injects a prefix, will it impact other routers which are not overflowing the source?
>> 【A-WAJ】:No. RR can control when to send the RD-ORF message to the upstream/source router.
>> For example, if only one PE overflow, RR can add the RD-ORF as its Adj-RIB-Out filter to this PE, and don’t send this message to the source PE, or other RR.
>> Theoretically, RR need only send such RD-ORF upstream when it can’t process the BGP Updates, or it is overflow.
>>  
>> 【Keyur】:The prefix filter level filtering has more expense than a higher level filters.
>> 【A-WAJ】:RD based filter is also higher level filter.  RT based filter can’t solve the problems that described in this draft.
>>  
>> 【Robert】: there was a number of technical problems sent to the list. None of these were addressed. This is not the right way to filter VPN
>> 【A-WAJ】:Would you like to point out which technical problem isn’t addressed yet?  We have also compared the existing solutions and their limitations in the draft and at the presentation.
>>  
>>  
>> Best Regards
>>  
>> Aijun Wang
>> China Telecom
>>  
>> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of wangw36@chinatelecom.cn
>> Sent: Tuesday, July 28, 2020 4:47 PM
>> To: idr <idr@ietf.org>
>> Subject: [Idr] New Version Notification for draft-wang-idr-rd-orf-01.txt
>>  
>> Hi,IDR experts:
>>  
>>     Based on the previous discussion with Robert and Jakob, we update our draft as follows:
>> ·       The differences between RD-ORF, RTC and Address Prefix ORF are briefly described;
>> ·       The encoding of RD-ORF type-specific part is changed and the source address sub TLV field is added;
>> ·       The application in single-domain scenario is added;
>> ·       Four new types of sub-TLV are defined to carry the source address in different scenarios.
>>     Any comments are welcome.
>>  
>> 
>> Best Regards.
>>  王巍  Wang Wei    
>> +86-010-5090-2397  
>> +86-177-7809-6050  
>> wangw36@chinatelecom.cn  
>> ------------------------------------------------------------------------  
>> CTNET2025研究所  
>> 中国电信股份有限公司北京研究院  
>> China Telecom Corporation Limited Beijing Research Institute  
>> 北京市昌平区北七家镇未来科技城南区中国电信北京信息科技创新园  
>> 邮编:102209 
>>  
>> From: internet-drafts
>> Date: 2020-07-28 16:17
>> To: Jie Dong; Aijun Wang; Shunwan Zhuang; Wei Wang; Haibo Wang
>> Subject: New Version Notification for draft-wang-idr-rd-orf-01.txt
>>  
>> A new version of I-D, draft-wang-idr-rd-orf-01.txt
>> has been successfully submitted by Wei Wang and posted to the
>> IETF repository.
>>  
>> Name: draft-wang-idr-rd-orf
>> Revision: 01
>> Title: Route Distinguisher Outbound Route Filter (RD-ORF) for BGP-4
>> Document date: 2020-07-28
>> Group: Individual Submission
>> Pages: 14
>> URL:            https://www.ietf.org/internet-drafts/draft-wang-idr-rd-orf-01.txt
>> Status:         https://datatracker.ietf.org/doc/draft-wang-idr-rd-orf/
>> Htmlized:       https://tools.ietf.org/html/draft-wang-idr-rd-orf-01
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-wang-idr-rd-orf
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-wang-idr-rd-orf-01
>>  
>> Abstract:
>>    This draft defines a new Outbound Route Filter (ORF) type, called the
>>    Route Distinguisher ORF (RD-ORF).  RD-ORF is applicable when the
>>    routers do not exchange VPN routing infomation directly (e.g. routers
>>    in single-domain connect via Route Reflector, or routers in Option B/
>>    Option C cross-domain scenario)..
>>  
>>                                                                                  
>>  
>>  
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>  
>> The IETF Secretariat
>>  
>>  
>>  
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr