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

[Jeffrey Haas <[e-mail]>]

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