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 16:09 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 3505C3A0C7D for <idr@ietfa.amsl.com>; Wed, 5 Aug 2020 09:09:13 -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 tlpFkcNaan77 for <idr@ietfa.amsl.com>; Wed, 5 Aug 2020 09:09:09 -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 99BA53A0C81 for <idr@ietf.org>; Wed, 5 Aug 2020 09:09:08 -0700 (PDT)
Received: from [240.0.0.1] (unknown [111.194.51.107]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id 306C949220; Thu, 6 Aug 2020 00:09:00 +0800 (CST)
Content-Type: multipart/alternative; boundary=Apple-Mail-47654C44-EA47-4DC2-B1C0-44633A7F524B
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Thu, 6 Aug 2020 00:08:59 +0800
Message-Id: <29F33044-129F-4C22-82BB-F3A01447594E@tsinghua.org.cn>
References: <CAOj+MMFDwoJqNY0pXBQEffVMv9-JukKSAmqZ3qMYySMKKD=i+Q@mail.gmail.com>
Cc: Keyur Patel <keyur@arrcus.com>, idr <idr@ietf.org>, wangw36@chinatelecom.cn
In-Reply-To: <CAOj+MMFDwoJqNY0pXBQEffVMv9-JukKSAmqZ3qMYySMKKD=i+Q@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: iPhone Mail (17F80)
X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZQktDS0hDQkJJT0xJVkpOQk1NT0hMT0tJQk1VEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0hKTFVKS0tZBg++
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6PxQ6Nio*FD8vIUsuNwkUCggM HC0aCThVSlVKTkJNTU9ITE9LTElDVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKSkpVSkJPVU5KVUpLTFlXWQgBWUFKSE9NSDcG
X-HM-Tid: 0a73bf620a299865kuuu306c949220
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/NdnHrwoM-74GnSqD38K8skNjA1A>
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 16:09:13 -0000

Hi, Robert:

Aijun Wang
China Telecom

> On Aug 5, 2020, at 23:35, Robert Raszuk <robert@raszuk.net> wrote:
> 
> 
> Aijun,
> 
>> [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.
>> 
> 
> That is incorrect. 
> 
> When you filter VPNv4 routes based on the RD you are suppressing this route say on remote PE or RR such that it will never arrive on the PE. 
> 
> And please kindly observe that VPNv4 routes carry a lot of RTs attached. So one VRF may import this route based on the RT1 and the other may import the same route based on the presence of RT2. 

[WAJ] The VPN routes imported in these VRFs can’t use the same RD, or else, the VPN prefixes in different VRFs will collision on RR.



> 
> That means that healthy VRF may no longer be able to import this route when you suppress it upstream in spite of the fact that there is no problem with overflow on a given VRF. 
> 
> Your scheme could work if we would assume no extranets nor more then one RT per VPNv4 route. But this is not the case in the specification nor in any deployment I have seen or run. 

[WAJ]  We have no any assumption on RT allocation.
> 
> 
>> 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.
>> 
> 
> It sure can. Just add one more RT to identify the VPN on export. You may not even ever import that RT anywhere. It would be used just as a VPN-ID in your network. 

[WAJ] Don’t you agree that such usage of RT is same as RD?

>  
>> 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.
>> 
> 
> There is no such a thing like an overflow PE. PE has different RIBs usually one per VRF. So ultimately the overflow is coming from a VRF. And as we proven that is not possible to avoid based on the RD filtering without affecting other VRFs. 

[WAJ] Will not affect other VRFs, as explained above.

> 
> It is a silent failure for customers as customers never see the RD-ORF. 
> 
> I would be willing to state that it may be better to fail such overflown PE other then trying to recover and keep it running on the clif by shaving of VPN routes arrving to it. Either such PE needs replacement or operator running such PE needs to update his resume. 
>  

[WAJ] Maybe it is not the overflown PE should be blamed?
>> [WAJ] RD-ORF just want to keep the disaster as small as possible, based on the parachutes J
>> 
> 
> We are here to avoid silent disasters. Or when it happens make a big enough boom. 

[WAJ] The overflown VRF/PE can log its state and then make this big enough boom?
> 
> Thx,
> R.
>