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

Aijun Wang <wangaj3@chinatelecom.cn> Thu, 25 February 2021 23:21 UTC

Return-Path: <wangaj3@chinatelecom.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 3CEC73A10AC; Thu, 25 Feb 2021 15:21:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 18hTH0ARNdVN; Thu, 25 Feb 2021 15:21:03 -0800 (PST)
Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.223]) by ietfa.amsl.com (Postfix) with ESMTP id AD4823A0FD1; Thu, 25 Feb 2021 15:20:53 -0800 (PST)
HMM_SOURCE_IP: 172.18.0.218:20255.75360390
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from clientip-111.194.46.55?logid-38524f115cd64a20ad956d2631524d48 (unknown [172.18.0.218]) by chinatelecom.cn (HERMES) with SMTP id 2951728009B; Fri, 26 Feb 2021 07:20:50 +0800 (CST)
X-189-SAVE-TO-SEND: 66040164@chinatelecom.cn
Received: from ([172.18.0.218]) by App0025 with ESMTP id 38524f115cd64a20ad956d2631524d48 for wangaijun@tsinghua.org.cn; Fri Feb 26 07:20:55 2021
X-Transaction-ID: 38524f115cd64a20ad956d2631524d48
X-filter-score: filter<0>
X-Real-From: wangaj3@chinatelecom.cn
X-Receive-IP: 172.18.0.218
X-MEDUSA-Status: 0
Sender: wangaj3@chinatelecom.cn
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Aijun Wang <wangaj3@chinatelecom.cn>
Mime-Version: 1.0 (1.0)
Date: Fri, 26 Feb 2021 07:20:45 +0800
Message-Id: <A7C19F05-DBCD-4AA8-ADC9-7F608BA9F540@chinatelecom.cn>
References: <20210225142155.GA27005@pfrc.org>
Cc: Aijun Wang <wangaijun@tsinghua.org.cn>, draft-wang-idr-rd-orf@ietf.org, idr@ietf.org
In-Reply-To: <20210225142155.GA27005@pfrc.org>
To: Jeffrey Haas <jhaas@pfrc.org>
X-Mailer: iPhone Mail (18D52)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/3MgEQE50zEN6L_UsQ959G9q8EDQ>
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: Thu, 25 Feb 2021 23:21:06 -0000

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. 
> 
> Thanks for the clarification.  That expands the scope of the original
> discussion, but might be helpful for the solution.
> 
>>> For a route reflector, it would require that all possible receivers for a
>>> RD/RT have no interest in the routes, and that the source of the routes is
>>> clearly directional.  BGP does not provide such a distribution graph.
>> 
>> [WAJ] " all its downstream BGP peers can't or don't want to process it"
>> means RR receives the RD-ORF messages for the same set of VPN routes from
>> all of its clients. This can be achieved by RR
> 
> For my point, consider a trivial case:
> 
> PE1 --- RR --- PE2
> 
> PE2 is the source of the excess routes.
> PE1 is the impacted router.
> RR has only PE1 and PE2 as peers.
> 
> By your current text, RR can only do something if PE1 and PE2 say they're
> not interested.
> 
> It can be observed here that if we have exactly one peer left, we could
> signal to that one peer.
> 
> I suspect your intent is to cover situations where you can distinguish PE
> routers from solely internal route distributuion infrastructure, such as
> route reflectors.  So, using a slighly more interesting topology:
> 
> PE1 --- RR1 --- RR2 --- PE2
> 
> PE2 is the source of the excess routes.
> PE1 is the impacted router.
> RR1 has only PE1 as a PE device.
> 
> If PE1 signals to RR1 that it isn't interested in the offending routes, RR1
> may propagate the filter.
> 
> The issue here is that BGP does not specifically distinguish whether an
> attached BGP Speaker is a PE or not.  The protocol doesn't help you make
> this determination.
> 
>>> In a network using RT-Constrain without a default RT-Constrain route, such a
>>> graph potentially exists.
>> [WAJ] RT-Constrain can only express explicitly "what I want" and the
>> distributed graph. It can't express explicitly "what I don't want" now, also
>> the distribution-block graph. Is that right?
> 
> That is correct.  But consider the following example:
> 
>        PE3
>         |
> PE1 --- RR1 --- RR2 --- PE2
> 
> PE2 is the source of the excess routes for VPN RT-A.
> PE1 is the impacted router.
> RR1 has PE1 and PE3 as attached PE routers.
> All routers are configured to use RT-Constrain
> PE1 and PE2 source RT-Constrain routes for RT-A.  PE3 does not.
> 
> If PE1 signals to RR1 that it isn't interested in the offending routes, and
> that signal not only includes the offending RD, but also the matching RTs,
> RR1 can determine that there are no further interested receivers for that
> RD+RT and propagate that to RR2.
> 
> RT-Constrain provides the ability to figure out what the interested
> receivers are for a VPN defined by a route-target.  This provides a
> restricted subset of the attached routers for propagation purposes.
> 
> -- Jeff
>