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

[Jie Dong <dongjie_dj at huawei.com>]

Hi, 

Thanks for your comments. Please see inline...

> > 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.
>
Yes, for VPNs with the same AFI/SAFI, different RT should be assigned for
different customers. 
 
> 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.
What we mean here is for different AFI/SAFIs the allocation of RT should be
able to operate independently. Operators can choose to use same or different
RT for different kinds of VPNs, either for same customer or different
customers. The assignment of RT can be quite flexible. Especially in
mutli-ISP scenarios, different ISP may use the same RT for different kind of
VPNs.

> 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.
If one customer belongs to L3VPN-1 and also L2VPN-2, the RTs for these two
VPNs are independent, they could use either different RT or same RT based on
the policy of the operator. 

> 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
Using same RT for multiple services is reasonable, however the sites may not
be identical for all these services. Some sites may only be interested in
some of these services, and more unneeded routes may get their PEs into
trouble. But with normal rt-constrain PEs of these sites will receive VPN
routes of all these services, including the unwanted ones. This can happen
especially during network migration and deployment of new services. As you
said, using different RT is not recommended, and using same RT some PEs need
the ability to notify others only some kind of routes are needed.

And as Mach has said before, compared with the quantity of unwanted routes
being advertised, the amount of RT-constrain information can be ignored.

> 
> 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.
Operators can choose how to manage their networks, and also different
operators can choose different ways. IMO we should provide methods to
lighten operators' burden on VPN service provisioning and assure that
different services will not affect each other.

Regards
Jie