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
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr