Hi Rajiv,
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>
Thanks for the references.
IMO, this description is about different customers' VPN of the same address
family (because this rfc only describes the procedures of L3VPNv4). But the
procedures of RT assignment among different kinds of VPNs are not explicitly
described.
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,
I agree that currently there is no clear description on RT assignment among
different kinds of VPNs. For this purpose, a document on this topic is good.
otherwise the lack of clarity
on this topic would continue to stir the confusion, resulting in the
undesired proposals and efforts.
It depends on whether the requirement is valid or not, and with detailed
analysis of the problems, it would make it clearer and may give us more
inputs to determine whether the proposals and efforts are needed.
Regards
Jie
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
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr