Re: [Idr] draft-wang-idr-vpn-routes-control-analysis (was Re: rd-orf problem clarification at the local level)

Aijun Wang <wangaijun@tsinghua.org.cn> Fri, 26 February 2021 11:26 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 303CD3A1370; Fri, 26 Feb 2021 03:26:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 266Po0PpjsRa; Fri, 26 Feb 2021 03:26:54 -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 B3F323A136F; Fri, 26 Feb 2021 03:26:53 -0800 (PST)
Received: from [240.0.0.1] (unknown [111.194.46.55]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id EE5F01C00D0; Fri, 26 Feb 2021 19:26:49 +0800 (CST)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Fri, 26 Feb 2021 19:26:48 +0800
Message-Id: <71BBA315-1E03-4DA8-A7F3-9DBAFBD55E26@tsinghua.org.cn>
References: <CAOj+MMGgY198Z4Uz8NBDMDMYtinBCauxtPxEojzhiQekJwOYaw@mail.gmail.com>
Cc: Gyan Mishra <hayabusagsm@gmail.com>, Aijun Wang <wangaj3@chinatelecom.cn>, draft-wang-idr-rd-orf@ietf.org, idr@ietf.org
In-Reply-To: <CAOj+MMGgY198Z4Uz8NBDMDMYtinBCauxtPxEojzhiQekJwOYaw@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: iPhone Mail (18D52)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZSUwdSU5KGRoaTk5KVkpNSk9ISENDSktLTkhVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0JITVVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Nyo6TAw*CT8NFxIBP0wYSSIv LiMaCR9VSlVKTUpPSEhDQ0pLT0pNVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKSkpVSkJPVU9NVU5OWVdZCAFZQU5MSkw3Bg++
X-HM-Tid: 0a77de17607ad993kuwsee5f01c00d0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/k53ddGo-gWOQMoK6LRjJVmnCSwI>
Subject: Re: [Idr] draft-wang-idr-vpn-routes-control-analysis (was Re: rd-orf problem clarification at the local level)
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, 26 Feb 2021 11:26:56 -0000

Hi, Robert:

Your proposal just let RTC act as the behavior of RD-ORF. 
I think no one will agree with you.

I think what Jeff’s proposal is to utilize the information from RTC to let the RR decide when to send out the RD-ORF message on behalf of its peers, not to change the behavior of RTC.


Aijun Wang
China Telecom

> On Feb 26, 2021, at 18:48, Robert Raszuk <robert@raszuk.net> wrote:
> 
> Gyan,
> 
> What you said is pretty obvious I think to everyone here.
> 
> But I think the point of bringing RTC into this picture was a bit
> different.
> 
> Just imagine RTC is running between PE and RR and signals interest in set
> of RTs to the RR. Let's say those RTs are RT100, RT200, RT300, RT400, RT500
> 
> Further imagine one VRF importing RT200 overflows on said PE with incoming
> (pre-import routes of RD_FOO and RT100, RT200 and RT 300).
> 
> So what if now PE via RTC will simply readvertise interest to get RT200
> with new BGP attribute say called BLOCK_RD and lists in such attribute body
> Route Distinguisher of RD_FOO ?

[WAJ] The action on RR then will be advertised VPN routes that with RT200, but the RD part is not RD_FOO?


> 
> The overall mission accomplished. No need for any new ORF type. It can be
> even transitive if we apply a little hack and adjust the way RR will select
> the best path for RTC (meaning include this attribute in advertisements
> only if all peers sending RT200 attached it with such RD_FOO).

[WAJ] Normally RTC message will be flooded within the network immediately . Your proposal here just let it wait responses from all its peers. If so, why using BGP UPDATE message?

> 
> To me this is very simply RTC extension and it seems solves this entire
> "problem".
> 
> And no - by proposing the above I am not changing my mind that it is simply
> wrong network operation to even allow such problem to happen in the first
> place.
> 
> Best,
> R.
> 
> 
>> On Fri, Feb 26, 2021 at 4:52 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:
>> 
>> 
>> Hi Jeff
>> 
>> Keep in mind that RTC is an optimization that does not apply to every
>> scenario especially in cases where all PEs have all the same VPNs defined
>> with explicit RT import.  The special cases were RTC does apply is for
>> incongruent VRFs in cases of a sparse RT distribution graph where PEs don’t
>> all import the same RTs.  By default all PE have RT filtering enabled by
>> default meaning if their is not an explicit VRF definition to match and
>> import the RT, the RT is dropped.  With RTC the distribution graph of what
>> RTs are advertised RR-PE is now optimized with RT membership, and now  only
>> RTs explicitly imported by the PEs are now advertised by the RR to PE for
>> processing.  In the case of RD-ORF, it provides a layer of needed
>> granularity as the RD PE originator of the flood is a subset of all the VPN
>> prefixes represented by the RT permitted by RTC to be advertised to the
>> PE.  The RD-ORF now dynamically blocks the offending PE prefixes that would
>> otherwise have been advertised by RTC RR to PE and accepted by the PE for
>> processing and added to the VRF RIB being overloaded.
>> 
>> 
>> Kind Regards
>> 
>> Gyan
>> 
>> On Thu, Feb 25, 2021 at 6:21 PM Aijun Wang <wangaj3@chinatelecom.cn>
>> wrote:
>> 
>>> Hi, Jeff:
>>> Thanks for your suggestions!
>>> I think combine RTC and RD-ORF information can accomplish the fine
>>> control for the upstream propagation of unwanted VPN routes.
>>> We will also try to find other ways to achieve the same effect.
>>> 
>>> Aijun Wang
>>> China Telecom
>>> 
>>>> On Feb 25, 2021, at 22:01, Jeffrey Haas <jhaas@pfrc.org> wrote:
>>>> 
>>>> Aijun,
>>>> 
>>>> On Thu, Feb 25, 2021 at 12:07:49PM +0800, Aijun Wang wrote:
>>>>>> In the prior discussions, it was clear that remediation was trying to
>>> be
>>>>>> done on a per-RD basis.  The text in this draft seems to be a larger
>>> scope
>>>>>> than that; perhaps per VPN (and thus route-target?).  Is that your
>>>>>> intention?
>>>>> [WAJ] Yes. We are considering to add RT information to the current
>>> RD-ORF
>>>>> semantic, to identify/control the "excessive routes" in more granular