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

[Jie Dong <dongjie_dj at huawei.com>]

Hi,

Thanks for clarifying this problem, that's one scenario of receiving
"unwanted" (Sorry for confusing on this.) routes: same RT is used by one
customer for different kind of VPNs. And another possible scenario is that
same RT is used by different customer for different kind of VPNs. In both
these cases PEs may receive "unwanted" routes.


Jie


> -----Original Message-----
> From: Rajiv Asati (rajiva) [mailto:rajiva at cisco.com]
> Sent: Wednesday, November 11, 2009 3:01 PM
> To: Robert Raszuk (raszuk); Jie Dong
> Cc: idr at ietf.org
> Subject: RE: [Idr] Response to comments on generalized RT constrain
solution
> 
> > 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