Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)

Aijun Wang <wangaijun@tsinghua.org.cn> Thu, 11 February 2021 16:11 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 4C0263A1714 for <idr@ietfa.amsl.com>; Thu, 11 Feb 2021 08:11:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level:
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 v43fzCQgRR78 for <idr@ietfa.amsl.com>; Thu, 11 Feb 2021 08:11:39 -0800 (PST)
Received: from mail-m17638.qiye.163.com (mail-m17638.qiye.163.com [59.111.176.38]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 752B13A1711 for <idr@ietf.org>; Thu, 11 Feb 2021 08:11:37 -0800 (PST)
Received: from [240.0.0.1] (unknown [111.194.46.85]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id 3EA551C0213; Fri, 12 Feb 2021 00:11:34 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-55320151-AE3A-4FEE-A61D-ADBF5C5069FA"
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Fri, 12 Feb 2021 00:11:33 +0800
Message-Id: <F2F3F1FC-B2B7-46BB-AE73-9EC15BC96A1A@tsinghua.org.cn>
References: <CAOj+MMEwF3JL6+CCmV2S1bB2OjU_iMGCj=waYhJAZAaMK=LRYQ@mail.gmail.com>
Cc: "Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>, Susan Hares <shares@ndzh.com>, idr@ietf.org, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>
In-Reply-To: <CAOj+MMEwF3JL6+CCmV2S1bB2OjU_iMGCj=waYhJAZAaMK=LRYQ@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: iPhone Mail (18D52)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZQh8ZSElJGhpLTRpIVkpNSkhLTkJDQk9ITklVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0NISFVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6MlE6SSo*DD8UEy0oAxYLH0gj DSMwCQtVSlVKTUpIS05CQ0JPTEpIVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKSkpVSkJPVU9NVUNOWVdZCAFZQUNITUk3Bg++
X-HM-Tid: 0a7791dcabf3d993kuws3ea551c0213
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/RCqHWMEaSP6-LAXUwybbaKwRy-c>
Subject: Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)
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: Thu, 11 Feb 2021 16:11:44 -0000

Hi, Robert:

Aijun Wang
China Telecom

> On Feb 11, 2021, at 23:40, Robert Raszuk <robert@raszuk.net> wrote:
> 
> 
> 
>>> Now if all of the above is not done or done with mistakes and you indeed experience to many routes to be handled by data plane you stop locally importing those routes to local VRFs by VRF shutdown. The good thing here is that this will be noticed by all attached customers as their dynamic routing will propagate withdraws. 
>> [WAJ] The BGP session is shared by several VPNs and cannot be shutdown in such situations. Procedures that you expect would not happen.
> 
> 
> Where did I say to shutdown BGP session ? 
> 
> I said VRF shutdown ... nothing to do with BGP sessions shutdown. 
> 
[WAJ] Don’t you think VRF shutdown has the more broader influences? RD-ORF influences only the newly advertised VPN routes. VRF shutdown will influence the existing VPN routes and its existing forwarding traffic.

> - - - 
> 
> Let me provide the analogy here ... 
> 
> You are presenting a solution on what to do when we fly low and start hitting the top of the trees. 
> 
> WG tells you that flying low is bad practice and should not take place providing what to do to mitigate it well - in the analogy train your ground crew not to overload the plane. 
> 
> You say - Oh well we have different idea instead - when we throw away during the flight some passengers we can keep flying (on the edge of safety). 
[WAJ] Just deny the onboard of new passengers, not throwing the existing passengers.
> 
> That's here we are with this. 
> 
> - - - 
> 
> Quite honestly when we started to deploy 2547 back in nearly 2000s we were preparing much more user friendly solution (a flavor of CSC - not CSC as defined in the RFC) where SP network would only deal with next hops and never with customer routes ... yet customer would have the same type of service. Quite honestly we have had even OSPF reflector ready for it. Problem was that at that time SPs said oh we want to take millions of customer routes - no problem. We just buy bigger RRs and bigger routers. So you can guess what happened with such idea - got shelved as if deployed would result in revenue loss :). 
> 
[WAJ] RD-ORF mechanism can encourage the provider to deploy inter-as VPN solutions because it gives them the granular control over the VPN routes propagation between ASBRs or RRs, which can certainly broader the VPN service coverage and the revenue.

> Best,
> R.
>