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

["Rajiv Asati (rajiva)" <rajiva at cisco.com>]

> 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.
> 
> I really don't see how this is related to SAFIs/services provided.

Allow me to justify this problem per the draft, though we can't yet
justify the solution:

~~~~~~~~~~~~~
Consider VPN customer A has 10 sites - siteA1, siteA2...siteA10.

All the sites need IPv4 any-to-any connectivity, however, only siteA1
and siteA2 need IPv6 connectivity.

If the VRF for VPN customer A is configured with the same RT set for
both IPv4 and IPv6 SAFIs on each PE connected to each of 10 sites, then
each PE router ends up with all IPv4 and IPv6 routes related to that
VPN. 

Of course, PEs connected to siteA3,...siteA10 should not care about the
IPv6 routes in that VPN since the sites don't need them. Hence, those
routes become unwanted routes.
~~~~~~~

I don't know if this is how the draft defines the "unwanted routes", but
that's my understanding based on the slides I saw yday.

Cheers,
Rajiv


> -----Original Message-----
> From: idr-bounces at ietf.org [mailto:idr-bounces at ietf.org] On Behalf Of
Robert
> Raszuk (raszuk)
> Sent: Tuesday, November 10, 2009 9:17 PM
> To: Jie Dong
> Cc: idr at ietf.org
> Subject: Re: [Idr] Response to comments on generalized RT constrain
solution
> 
> Jie,
> 
> > 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.
> 
> 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.
> 
> Cheers,
> R.
> 
> 
> > 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
> >
> 
> _______________________________________________
> Idr mailing list
> Idr at ietf.org
> https://www.ietf.org/mailman/listinfo/idr