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

Jeffrey Haas <jhaas@pfrc.org> Wed, 24 February 2021 21:01 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 C17273A1B4E; Wed, 24 Feb 2021 13:01:09 -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 hAo8-js-mpv2; Wed, 24 Feb 2021 13:01:07 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9926F3A1B4F; Wed, 24 Feb 2021 13:01:07 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 17C041E3D0; Wed, 24 Feb 2021 16:21:38 -0500 (EST)
Date: Wed, 24 Feb 2021 16:21:38 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: Aijun Wang <wangaijun@tsinghua.org.cn>
Cc: 'Aijun Wang' <wangaj3@chinatelecom.cn>, draft-wang-idr-rd-orf@ietf.org, idr@ietf.org
Message-ID: <20210224212137.GE18618@pfrc.org>
References: <FD5D3158-FA7D-4C57-932D-4A0A421621F3@chinatelecom.cn> <00d501d70906$f4625de0$dd2719a0$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00d501d70906$f4625de0$dd2719a0$@tsinghua.org.cn>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/mlFpXAv1afdJN0d0SRO2MxtUTOA>
Subject: [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: Wed, 24 Feb 2021 21:01:10 -0000

Aijun,

On Mon, Feb 22, 2021 at 06:39:10PM +0800, Aijun Wang wrote:
> We have upload one new draft to describe the problems that related to the VPN routes control in shared BGP session https://datatracker.ietf.org/doc/html/draft-wang-idr-vpn-routes-control-analysis
> 
> Wish to hear your considerations and comments on such analysis.
> 
> If we can consensus on the scenarios analysis and the solution requirements, we can focus on the potential solutions in next step.

Thanks for separating out the scenarios.  It may help focus the conversation
on what may be able to be functionally done via BGP without also working
through the specific details of a proposed protocol change.

I have two broad comments on this draft:

1. 
The use cases are helpful in describing route distribution scenarios for VPN
routes for this problem of "excess routes".  However, the scenarios are not
equally clear about identifying routes for a given VPN that can be
remediated.

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?

2.
In section 8, "Requirements for the solutions", b) (second one, you need to
renumber!), you state:

:  b) For RR and ASBR devices, such control message should be only
:  flooded to its upstream BGP neighbor when all its downstream BGP
:  peers can't or don't want to process it, or the process of such
:  excessive routes has exceed its own capability.

Previous discussion regarding rd-orf showed that there is a strong challenge
to determining that there are no interested downstream receivers.  You will
need to document the scenarios where this can be clearly demonstrated.

A few examples:
For a PE, all CE instances do not want this RD or RT.  If there is no
inter-as VPN, this is a clear condition.

All remaining scenarios introduce ambiguity, I think.

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.

In a network using RT-Constrain without a default RT-Constrain route, such a
graph potentially exists.

-- Jeff