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

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

Hi Jie,

The former scenario is questionable, whereas the latter scenario is
invalid. Please see my earlier email and reference to RFC4364 section
4.3.5. 

Nonetheless, you have brought up a good point that deserves further
clarity about different SAFIs per VRF wrt RFC4364, at minimum.

Cheers,
Rajiv

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