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> Fri, 12 February 2021 14:47 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 0402F3A1749 for <idr@ietfa.amsl.com>; Fri, 12 Feb 2021 06:47:58 -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=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 nLoEplBsAWVf for <idr@ietfa.amsl.com>; Fri, 12 Feb 2021 06:47:55 -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 7B2AE3A1748 for <idr@ietf.org>; Fri, 12 Feb 2021 06:47:52 -0800 (PST)
Received: from [240.0.0.1] (unknown [111.194.46.85]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id D26681C0122; Fri, 12 Feb 2021 22:47:47 +0800 (CST)
Content-Type: multipart/alternative; boundary=Apple-Mail-DE260740-1808-4DD7-9F26-7020CF4D219B
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Fri, 12 Feb 2021 22:47:47 +0800
Message-Id: <36E84C9A-60C8-4A5C-8774-AA135AE1CD09@tsinghua.org.cn>
References: <CAOj+MMFUk8OXkt-gL1bOxEwqh0e2Da4K-jiMOzZ76iN8cpgQkw@mail.gmail.com>
Cc: Gyan Mishra <hayabusagsm@gmail.com>, "Jakob Heitz (jheitz)" <jheitz@cisco.com>, Susan Hares <shares@ndzh.com>, idr@ietf.org
In-Reply-To: <CAOj+MMFUk8OXkt-gL1bOxEwqh0e2Da4K-jiMOzZ76iN8cpgQkw@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: iPhone Mail (18D52)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZSUgaTE1DTUwYShhPVkpNSkhKT0pJTUxCT01VEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0JITVVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Ny46CTo*Nz8cEy1WFDUhKwI5 EkgKFCpVSlVKTUpISk9KSU1DSEpDVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKSkpVSkJPVU9NVUNOWVdZCAFZQUNMSks3Bg++
X-HM-Tid: 0a7796b65598d993kuwsd26681c0122
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/P4DpeOUelx1qEdGS03ACB-U1k0s>
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: Fri, 12 Feb 2021 14:48:04 -0000

Hi, Robert:

https://datatracker.ietf.org/doc/html/draft-wang-idr-rd-orf-05#section-5.1.1 has described such situations, which will require the additional local decisions of PE2 to judge whether to send the RD-ORF message out.
In your example, if only the HUB VRF exceed but the resources of PE2 is not exhausted, then the PE2 will not send the RD-ORF message. It may just discard the excessive 100000/32 routes.
If the resources of PE2 is nearly exhausted, it must send the RD-ORF message out. Or else not only the Spoke VRF, but also other VPNs on this device can’t be used.

Regarding to RR, it is the same principle: if RR can cope with such flooding, it need not send out RD-ORF to PE1. If RR can’t cope with, it must send out the RD-ORF message, or else not only the VPN that import RD X1 routes can’t work, but also other VPNs that don’t import RD x1 routes.

RD-ORF mechanism just keep the influences as small as possible.

Wish the above explanation can refresh your review of this draft.

We are also hopeful to invite you join us to make RD-ORF mechanism more robust and meet the critical challenges.

Aijun Wang
China Telecom

> On Feb 12, 2021, at 19:30, Robert Raszuk <robert@raszuk.net> wrote:
> 
> 
> Aijun & Gyan,
> 
> Let me try one more (hopefully last time) to explain to both of you - and for that matter to anyone how supported this adoption. 
> 
> Let's consider very typical Hub and Spoke scenario as illustrated below: 
> 
> <image.png>
> 
> 
> HQ1 is advertising two routes:
> 
> - one default with RDX1 with RT TO_SPOKE 
> - one or more specifics with RDX1 to the other HUBs
> 
> Now imagine HQ1 bought a new BGP "Optimizer" and suddenly is starting to advertise 100000 /32 routes just to the other HUB with RT: TO_HUB. 
> 
> <image.png>
> 
> 
> 
> So PE2 detects this as VRF with RDX2 on it got overwhelmed during import with RT TO_HUB and starts pushing RDX1 (original RD) to RR to stop getting those routes. 
> 
> Well all great except now you are throwing baby with the water as all spokes attached to PE2 which just import default route to HUB HQ1 also can no longer reach their hub site as their default route will be removed. Therefor they will have nothing to import with RT:TO_SPOKE
> 
> Further if RR "independently" decided ... oh let's push this ORF to PE1 then all of the spokes attached to perhaps even much more powerful PE3 can also no longer reach their headquarters. 
> 
> - - - 
> 
> Summary: 
> 
> The above clearly illustrates why the proposed solution to use RD for filtering is in fact harmful. 
> 
> See when you design new protocol extensions the difficulty is to not break any existing protocols and deployments.
> 
> Hope this puts this long thread to rest now. 
> 
> 
> Thx,
> Robert
>