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

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

Firstly, assigning the same RT to two different customers' VPN inside
the SP network must be avoided (unless the intent is that two VPNs need
each others' routes). It is indeed a misconfiguration. In fact, this is
explicitly outlined in section 4.3.5 of RFC4364.

<excerpt>
   Then each site is associated with a VRF, a single Route Target
   attribute is chosen, that Route Target is assigned to each VRF as
   both the Import Target and the Export Target, and that Route Target
   is not assigned to any other VRFs as either the Import Target or the
   Export Target.
</excerpt>


Secondly, assigning the same RT to different (sub) address-families
belonging to the same customer' VPN inside the SP network should not be
permitted unless they result in the congruent topologies. If they don't,
then the customer sites should be perceived to belonging to different
VPNs (one for IPv4 and the other for IPv6, say), requiring two different
RT value(s).

	In the contrary, if each customer site needs both 
	IPv4 and IPv6 routes, then each site participates 
	in congruent IPv4 and IPv6 topologies. Hence, same 
	RT (set) could be utilized in the VRF.

Unfortunately, RFC4364 is not explicit about this. While one may deduce
the above from the section 4.3.5 of RFC4364, the section 4.3.1 paints a
different picture:

<excerpt>

   A Route Target attribute can be thought of as identifying a set of
   sites.  (Though it would be more precise to think of it as
   identifying a set of VRFs.)  Associating a particular Route Target
   attribute with a route allows that route to be placed in the VRFs
   that are used for routing traffic that is received from the
   corresponding sites.

</excerpt>

Unfortunately, the RFC4659 (VPNv6) is moot on this topic. We need to
write a document to clarify this better, otherwise the lack of clarity
on this topic would continue to stir the confusion, resulting in the
undesired proposals and efforts.

Cheers,
Rajiv


> -----Original Message-----
> From: idr-bounces at ietf.org [mailto:idr-bounces at ietf.org] On Behalf Of
Mach
> Chen
> Sent: Tuesday, November 10, 2009 11:30 PM
> To: Robert Raszuk (raszuk); Jie Dong
> Cc: idr at ietf.org
> Subject: Re: [Idr] Response to comments on generalized RT constrain
solution
> 
> Hi Robert,
> 
> > 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
> 
> Exactly, this is one of the issues that may lead to sending/receiving
> unnecessary VPN routes.
> 
> > Y. That would be IMHO a misconfiguration.
> 
> Why do you think this is misconfiguration? By your logic, does it mean
the
> configuration of one type of VPN will restrict and/or be restricted by
other
> types of VPNs. If things like this, it will affect the flexibility of
the
> deployment/provisioning of VPNs. And that, especially in inter-domain
> scenarios, it may be difficult/impossible to apply this restriction.
> 
> 
> Best regards,
> Mach
> 
> --------------------------------------------------
> From: "Robert Raszuk" <raszuk at cisco.com>
> Sent: Wednesday, November 11, 2009 10:17 AM
> To: "Jie Dong" <dongjie_dj at huawei.com>
> Cc: "'Pedro Marques (roque)'" <roque at cisco.com>; "'Mach Chen'"
> <mach at huawei.com>; <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