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

[Jie Dong <dongjie_dj at huawei.com>]

Hi Robert, 

> > But with normal rt-constrain PEs of these sites will receive VPN
> > routes of all these services, including the unwanted ones.
> 
> I don't understand the definition of "unwanted routes" in the draft and
> in your email description.
> 
> If RT is assigned that matches the routes they are received and
> accepted. If RT attached to the route is not part of import of any VRF
> of the PE they are dropped today and with rt-constrain will not be sent.
> 
If attached RT of VPNv6 routes matches the imported RT for VPNv4 routes on
one PE, with normal rt-constrain that VPNv6 routes can also be sent to that
PE. These routes are not what the PE wants. Note that PE may want VPNv6
routes of another VPN, thus the AFI/SAFI capability negotiation indicates
that PE is VPNv6 capable.

> I really don't see how this is related to SAFIs/services provided.
> 
> In fact if you don't have service ABC configured on such PE in question
> it will not receive any routes either today or with rt-constrain. Please
> observe that rt-constrain is just a filter not the request for routes.
>
> I think what you are trying to express is to assing on one PE 100:1 for
> L3VPNs for customer X and on the other PE 100:1 for L2VPNs for customer
> Y. That would be IMHO a misconfiguration.

If this is a misconfiguration, then RTs used by L3VPN cannot be used for
L2VPN. This is a restriction to deployment of different kind of VPNs. And in
this way, different kind of VPNs cannot be operated and managed
independently, do you think this is reasonable? In most networks different
kind of VPNs are deployed gradually based on the demand of customers. Thus
it is impossible to make a plan for deployment of all kinds of VPNs at the
beginning. And this would also affect the flexibility of deployment of new
VPN services.

Also, I would like to remind you of the problem with length of the RT field.
It is another problem our draft proposes to solve.


Regards
Jie

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