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

[Aijun Wang <[e-mail]>]

Hi, Jeffrey:

Thanks for your review of this draft. 
More comments on the scenarios described in this document and additional
scenarios are welcome.


Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: [e-mail] <[e-mail]> On Behalf Of Jeffrey Haas
Sent: Thursday, February 25, 2021 5:22 AM
To: Aijun Wang <[e-mail]>
Cc: 'Aijun Wang' <[e-mail]>; [e-mail];
[e-mail]
Subject: draft-wang-idr-vpn-routes-control-analysis (was Re: [Idr] rd-orf
problem clarification at the local level)

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-contro
> l-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?
[WAJ] Yes. We are considering to add RT information to the current RD-ORF
semantic, to identify/control the "excessive routes" in more granular. 
In figure 1 of this draft, if RD is allocated per VRF per PE(for example for
VPN1), then the RD only is enough to identify the "excessive routes". 
But there are situations that RD is not unique across different VRFs on one
PE(although not common, but may exist, will try to add such illustration in
Figure 1 in update version). In such situation, additional information is
help and necessary.

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.
[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

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?

-- Jeff