Re: [Idr] Response to comments on generalized RT constrain solution

["Pedro Marques (roque)" <roque at cisco.com>]

> The issue we really concern is that the RTs overlap among different
> customers. Different VPNs for different customers may be configiured
to
> used
> same RT, that means the RT of one type of VPN may attracted unwanted
> routes
> belong to other types of VPNS, and that the RT
> configuration/modification of
> one type VPN may affect the other VPNs that are totally not relevant
to
> that
> VPN.

I'm not sure I follow your argument. Clearly if we are talking about
VPNs with the same address family you can't use the same RT for
different VPNs. For a VPN service to operate correctly the provisioning
mechanism should be able to assign an unique RT per VPN.

Now, even if you had the ability to use the same RT value across
different address families you most likely wouldn't want to use it. For
example, if customer A has a VPN with v4 service and customer B has a
VPN with v6 service it would be a *really bad idea* to assign the same
value to both because A may want to have v6 service in the future or
vice-versa.

The main point here is that in practice RT assignment is not per AF but
per VPN. That is the reason the rt constraint draft handles the RT
independently of the AF.

It seems to me that attempts to have RT constraint have per AF semantics
are misguided in the least. A VPN will very likely have multiple
services that use different BGP AFI,SAFIs and while in theory they could
use multiple RTs there is no practical value in doing so. That would
result in having to advertise multiple times the same information when
using rt-constraint.

In my mind, the question we should ask is: would a service provider use
the same customer id for 2 different customers (even if they have
different services ?). The answer is no. The same way the SP
provisioning system should be able to assign unique RTs per customer so
that ops can retrieve the customer-id from the RT.

  Pedro.