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

From: Jie Dong <[email-masked]>
Date: Tue, 10 Nov 2009 14:31:03 +0900

Hi Robert,

Thanks for your comments. 

My three points here:

1. By carefully configuring the RTs may resolve the issues raised in our
draft (e.g., in small/simple networks, there are not so much VPNs deployed
in the network).  But with the increment of the size/VPNs of the network, it
requires that the operators have to assign RTs very carefully to make sure
there is no overlapping between RT spaces of different kind of VPNs, this
sometime may be a big burden for SPs. And this might be easy for networks
which is operated by only one operator, but is quite difficult for networks
operated by many ISPs.

2. With the current mechanisms, there is possibility that the deployment of
a new VPN affects the existing network, and sometimes it may lead to
unexpected situations. IMO this is the worst thing that operators do not
want to see. 

3. BTW, there is another issue regarding to the length of the RT filed, the
IPv6 address specified RT is covered in rfc4684.

Regards

Jie

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 10 Nov 2009 15:48:10 +0900

Hi Jie,

 > draft (e.g., in small/simple networks, there are not so much VPNs
 > deployed in the network).  But with the increment of the size/VPNs of
 > the network, it requires that the operators have to assign RTs very
 > carefully to make sure there is no overlapping between RT spaces of
 > different kind of VPNs,

I don't think this is of any mandatory requirement to make sure that RTs 
are specified unique between different kinds of VPNs of a given customer.

In particular if you have customer interested in using IPv4 and IPv6 
addressing I would in fact very much suggest to set the RTs to be a 
descriptive reflection of such customer sites and be of the same value.

For customers using l2VPN and L3VPNs or MVPNs those also will be 
congruent with a given customer sites. In fact it would be a mistake to 
specify different RTs for IP unicast and for MVPN in most cases.

Of course between different customer's VPNs you need different RT values 
but this is basic provisioning requirement for BGP VPNs application.

 > this sometime may be a big burden for SPs. And
 > this might be easy for networks which is operated by only one
 > operator, but is quite difficult for networks operated by many ISPs.

There is already very well defined set of procedures to provide inter-as 
VPNs for any type of VPN. I am not sure if your draft would make it any 
easier to send RTs separately for different SAFIs.

In worst case the consequence of splitting RT space may result in 
duplicating identical RT information to be distributed many times.

 > 2. With the current mechanisms, there is possibility that the
 > deployment of a new VPN affects the existing network, and sometimes it
 > may lead to unexpected situations. IMO this is the worst thing that
 > operators do not want to see.

I don't see what unexpected situations may arise. Can you provide some 
examples here ?

 > 3. BTW, there is another issue regarding to the length of the RT
 > filed, the IPv6 address specified RT is covered in rfc4684.

Can you clarify what is the issue ?

Many thx,
R.

> draft (e.g., in small/simple networks, there are not so much VPNs 
> deployed in the network).  But with the increment of the size/VPNs of 
> the network, it requires that the operators have to assign RTs very 
> carefully to make sure there is no overlapping between RT spaces of 
> different kind of VPNs, this sometime may be a big burden for SPs. And 
> this might be easy for networks which is operated by only one operator, 
> but is quite difficult for networks operated by many ISPs.
> 
>  
> 
> 2. With the current mechanisms, there is possibility that the deployment 
> of a new VPN affects the existing network, and sometimes it may lead to 
> 3. BTW, there is another issue regarding to the length of the RT filed, 
> the IPv6 address specified RT is covered in rfc4684.
> 
>  
> 
> Regards
> 
> Jie
>

---

From: Mach Chen <[email-masked]>
Date: Wed, 11 Nov 2009 00:10:00 +0800

Hi Robert,

Fogive me to chime in.

Please see inline...

> are specified unique between different kinds of VPNs of a given customer.

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.

> descriptive reflection of such customer sites and be of the same value.
A fine decription of a specific RT may help the opertor to admin their VPNs 
deloyment, but it could not change the essence of the existing RT-constrian 
that it may lead to RTs overlap or conflicts among dififferent VPNs.

>
> For customers using l2VPN and L3VPNs or MVPNs those also will be congruent 
> with a given customer sites. In fact it would be a mistake to specify 
> different RTs for IP unicast and for MVPN in most cases.
>
Different customers serviced with the same kinds of VPN, of cause, RT should 
be set to different values. As I said above, different customers serviced 
with different kinds of VPNs, it SHOULD not be required to use different 
values anymore.

> easier to send RTs separately for different SAFIs.

In our draft, we firstly propose to send RTs separately for different AFIs, 
and of cause, if we could differentiate different SAFIs(it is also proposed 
in the draft), that will be better. With these extensions, there will (and 
SHOULD) be no affection/relationship among different kinds of VPNs anymore.
> duplicating identical RT information to be distributed many times.

IMO, compare to the unwanted routes sending/processing and the underlying 
affection among VPNs, it could be ignored.
> I don't see what unexpected situations may arise. Can you provide some 

For a BGP router, with the current BT-constrian mechansims, it's possilbe 
that it may received some out-of-expectation routes, and these routes may 
make the number of the routes of that router reaching to a threshold that 
may triger the router to disconnect BGP sessions.

> Can you clarify what is the issue ?

Here is the RT difinition in RFC4684:
+-------------------------------+
| origin as        (4 octets)   |
+-------------------------------+
| route target     (8 octets)   |
+                               +
|                               |
+-------------------------------+

There is only 8 octets left for route target.

Best regards,
Mach

>> deployed in the network).  But with the increment of the size/VPNs of the 
>> network, it requires that the operators have to assign RTs very carefully 
>> to make sure there is no overlapping between RT spaces of different kind 
>> of VPNs, this sometime may be a big burden for SPs. And this might be 
>> easy for networks which is operated by only one operator, but is quite 
>> difficult for networks operated by many ISPs.
>>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: "Pedro Marques (roque)" <[email-masked]>
Date: Tue, 10 Nov 2009 08:31:43 -0800

> customers. Different VPNs for different customers may be configiured
to
> used
> one type VPN may affect the other VPNs that are totally not relevant
to
> that

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.

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.

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.

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.

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.

  Pedro.

---

From: Jie Dong <[email-masked]>
Date: Wed, 11 Nov 2009 10:59:39 +0900

Hi, 

Thanks for your comments. Please see inline...

> 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. 
 
> value to both because A may want to have v6 service in the future or
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.

> per VPN. That is the reason the rt constraint draft handles the RT
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. 

> 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.

> 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

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 11 Nov 2009 11:17:25 +0900

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.

---

From: Mach Chen <[email-masked]>
Date: Wed, 11 Nov 2009 12:30:02 +0800

Hi Robert,

> 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" <[email-masked]>
Sent: Wednesday, November 11, 2009 10:17 AM
To: "Jie Dong" <[email-masked]>
Cc: "'Pedro Marques (roque)'" <[email-masked]>; "'Mach Chen'" 
<[email-masked]>; <[email-masked]>
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.
>
> 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 
> 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...
>>

---

From: Jie Dong <[email-masked]>
Date: Wed, 11 Nov 2009 14:13:53 +0900

Hi Robert, 

> of the PE they are dropped today and with rt-constrain will not be sent.
If attached RT of VPNv6 routes matches the imported RT for VPNv4 routes on
one PE, with normal rt-constrain that VPNv6 routes can also be sent to that
PE. These routes are not what the PE wants. Note that PE may want VPNv6
routes of another VPN, thus the AFI/SAFI capability negotiation indicates
that PE is VPNv6 capable.

> Y. That would be IMHO a misconfiguration.

If this is a misconfiguration, then RTs used by L3VPN cannot be used for
L2VPN. This is a restriction to deployment of different kind of VPNs. And in
this way, different kind of VPNs cannot be operated and managed
independently, do you think this is reasonable? In most networks different
kind of VPNs are deployed gradually based on the demand of customers. Thus
it is impossible to make a plan for deployment of all kinds of VPNs at the
beginning. And this would also affect the flexibility of deployment of new
VPN services.

Also, I would like to remind you of the problem with length of the RT field.
It is another problem our draft proposes to solve.

Regards
Jie

> > mutli-ISP scenarios, different ISP may use the same RT for different
kind
> of
> > VPNs are independent, they could use either different RT or same RT
based
> on

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 11 Nov 2009 14:31:12 +0900

> Here is the RT difinition in RFC4684:

Why do you need more ? RFC4360 is quite clear on route target format and 
it is 8 octets.

RFC4684 just talks about IPv4 or IPv6 next hops to be used as part of 
MP_REACH_NLRI. That has nothing to do with different RT format.

Cheers,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 11 Nov 2009 14:40:41 +0900

Jie,

> In most networks different

There is many years of operational experience in deployment of various 
VPN services today. AFAIK non of the deployments today have found this 
to be of any practical issue.

I think it would be great at this point to hear from operator's 
community if they see a recommendation for unique RT assignment for 
different customers/services as a problem.

Thx,
R.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 11 Nov 2009 00:00:41 -0600

> 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: [email-masked] [mailto:[email-masked]] On Behalf Of
Robert
> Raszuk (raszuk)
> Sent: Tuesday, November 10, 2009 9:17 PM
> To: Jie Dong
> Cc: [email-masked]
> >>> same RT, that means the RT of one type of VPN may attracted
unwanted
> >>> routes
kind of
> > VPNs are independent, they could use either different RT or same RT
based on

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 11 Nov 2009 00:01:29 -0600

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

Mach
> Chen
> Sent: Tuesday, November 10, 2009 11:30 PM
> To: Robert Raszuk (raszuk); Jie Dong
> Cc: [email-masked]
accepted.
unwanted
> >> What we mean here is for different AFI/SAFIs the allocation of RT
should
> >> be
> >> mutli-ISP scenarios, different ISP may use the same RT for
different kind
> >> If one customer belongs to L3VPN-1 and also L2VPN-2, the RTs for
these
> >> two
based
> >> Using same RT for multiple services is reasonable, however the
sites may
> >> not
> >> 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

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 11 Nov 2009 00:09:03 -0600

If the RT is specified using 'draft-ietf-l3vpn-v6-ext-communities' (20
octets), then how would it fit in the RT definition of RFC4684 (8
octets)? 

Not sure if this is what Mach is alluding to, but I do see this as an
issue.

Cheers,
Rajiv

Robert
> Raszuk (raszuk)
> Sent: Wednesday, November 11, 2009 12:31 AM
> To: Mach Chen
> Cc: [email-masked]

---

From: Mach Chen <[email-masked]>
Date: Wed, 11 Nov 2009 14:16:05 +0800

Hi Robert,

IPv6 address specified RT (length of 20 bytes) is defined in 
http://tools.ietf.org/html/draft-ietf-l3vpn-v6-ext-communities-02, and RFC 
4684 does not support this new RT.

Best regards,
Mach

--------------------------------------------------
From: "Robert Raszuk" <[email-masked]>
Sent: Wednesday, November 11, 2009 1:31 PM
To: "Mach Chen" <[email-masked]>
Cc: <[email-masked]>; "Dong Jie" <[email-masked]>
Subject: Re: [Idr] Response to comments on generalized RT constrain solution

---

From: Mach Chen <[email-masked]>
Date: Wed, 11 Nov 2009 14:18:10 +0800

Hi Rajiv,

> Not sure if this is what Mach is alluding to, but I do see this as an

Correctly!

Best regards,
Mach

---

From: Jie Dong <[email-masked]>
Date: Wed, 11 Nov 2009 15:25:48 +0900

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

> From: Rajiv Asati (rajiva) [mailto:[email-masked]]
> Sent: Wednesday, November 11, 2009 3:01 PM
> Subject: RE: [Idr] Response to comments on generalized RT constrain
solution
> should be
> these two
> As you
> PEs need

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 11 Nov 2009 00:48:10 -0600

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

> From: Jie Dong [mailto:[email-masked]]
> Sent: Wednesday, November 11, 2009 1:26 AM
> To: Rajiv Asati (rajiva); Robert Raszuk (raszuk)
> Cc: [email-masked]
solution
> > > I don't understand the definition of "unwanted routes" in the
draft
> > and
> > > Subject: Re: [Idr] Response to comments on generalized RT
constrain
> > > I don't understand the definition of "unwanted routes" in the
draft
> > and
> > > I think what you are trying to express is to assing on one PE
100:1
> > for
> > > >> 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
> > > > able to operate independently. Operators can choose to use same
or
> > different
different
> > kind of
> > > > VPNs.
> > > >
> > > >> The main point here is that in practice RT assignment is not
per AF
> > but
> > > >> services that use different BGP AFI,SAFIs and while in theory
they
> > could
> > > >> result in having to advertise multiple times the same
information
> > when
sites
> > may not
> > > > some of these services, and more unneeded routes may get their
PEs
> > into
> > > > routes of all these services, including the unwanted ones. This
can
> > happen
> > > > And as Mach has said before, compared with the quantity of
unwanted
> > > >> In my mind, the question we should ask is: would a service
provider
> > use
> > > > operators can choose different ways. IMO we should provide
methods

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 11 Nov 2009 21:07:16 +0900

Mach,

You are correct that RFC4684 does not support this new RT as proposed by 
draft-ietf-l3vpn-v6-ext-communities-02. RFC4684 supports what BGP VPN 
defined by RFC 4364 or any other VPN specification which uses Route 
Target ext community attribute. That is all what is sufficient to be 
supported.

If we are discussing in particular RFC 4364 it's _normative_ reference 
explicitly states that Route Target ext community for all possible 
applications must be supported as defined in RFC 4360.

So first I recommend to wait for new version of RFC4364 with new 
normative reference section which would potentially refer to RFC XYZ 
which could be perhaps created one day by progressing 
draft-ietf-l3vpn-v6-ext-communities further.

At this point draft-ietf-l3vpn-v6-ext-communities is not applicable to 
RFC 4364 or any other VPN specification I am aware of.

In fact I do not know what draft-ietf-l3vpn-v6-ext-communities is 
applicable for. Perhaps it's author could clarify this on this list.

Cheers,
R.

> http://tools.ietf.org/html/draft-ietf-l3vpn-v6-ext-communities-02, and 
> RFC 4684 does not support this new RT.
> 
> Best regards,
> Mach
> 
>> Why do you need more ? RFC4360 is quite clear on route target format 
>> and it is 8 octets.
>>

---

From: Jie Dong <[email-masked]>
Date: Wed, 11 Nov 2009 21:13:33 +0900

Hi Rajiv, 

>    is not assigned to any other VRFs as either the Import Target or the

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.

> 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
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

> it. For
> has a
> provider use

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 11 Nov 2009 21:26:07 +0900

Jie and Rajiv,

 > 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.

I disagree.

RT assignment purposely and not by omission has not been specified by 
keystroke by the original spec to allow various levels of VPN topology 
flexibilities.

Document on this topic would be as useful as a document on how any ISP 
should define it's internal BGP policies.

Again let me reiterate that this is not up to any equipment vendor to 
decide if given standard specification they offer is easy to use or not. 
This is up to the operators' community to voice such concerns and as far 
as I can tell we have zero prove that what any VPN specification which 
uses RT based filtering there is any provisioning problem.

Cheers,
R.

---

From: Russ White <[email-masked]>
Date: Thu, 12 Nov 2009 09:09:54 +0900

> clarity about different SAFIs per VRF wrt RFC4364, at minimum.

I think it's worthwhile to pursue a bis on 4364 to clarify the usage of
the RT to avoid the problem described--although I also think it's pretty
much "common sense" to avoid it in the design and operation stages. I
don't think we need to change make RT constrain as contained in the
presented draft, as this would likely just add more confusion, and
probably wouldn't be deployed in the real world, because of the
additional configuration overhead involved.

Russ

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 12 Nov 2009 09:29:04 +0900

Hi Russ,

 > I think it's worthwhile to pursue a bis on 4364 to clarify the usage
 > of the RT to avoid the problem described-

Usage of RTs in RFC4364 is very clear. It has been deployed for over 9 
years and AFAIK the flexibility RFC4364 leaves as far as RT assignment 
did not generated any confusion, but allowed different VPN topologies to 
be build without spelling out each one in the spec.

The "problem" described here may come from using RTs between other 
applications which utilize the same extended community other then 4364 
examples: l2vpns, vpls, mvpn etc... So bis on 4364 seems like not right 
choice at all.

On the other hand if 4364 should ever adopt different RT format and 
specifically IPv6 address specific RT format the bis or new RFC update 
is required. But that is a separate issue from RT deployment recommendation.

Cheers,
R.

---

From: Mach Chen <[email-masked]>
Date: Thu, 12 Nov 2009 08:54:12 +0800

Hi Robert,

> years and AFAIK the flexibility RFC4364 leaves as far as RT assignment did 
> not generated any confusion, but allowed different VPN topologies to be 
> build without spelling out each one in the spec.

If there is no RT-constrain, yes,there will be no any confusion, because the 
RT space for different AFI/SAFI is actually seperated. The operator could 
assign RTs freely for a specific VPN without considering(and IMHO, it SHOULD 
NOT) any other type of VPNs. Otherwise, when configure L3VPN, if you have to 
consider the underlying confilicts with other type of VPNs, for me, that 
will be an annoying thing.

Best regards,
Mach

---

From: "Pedro Marques (roque)" <[email-masked]>
Date: Wed, 11 Nov 2009 17:18:58 -0800

Mach,

> NOT) any other type of VPNs.

I disagree. There are very strong practical reasons why the operator
would want to make sure it can determine the VPN from the RT. VPNs will
have different services (e.g. v4/v6/mcast) enabled on them and policy is
expressed in terms of VPNs. That includes policy in ASBRs, etc.
In practice and operator will want to assign RTs per VPN and not per
(AF, VPN). rt-constraint doesn't change this equation a bit.

On the other hand I see no harm in an informational document that states
that life is much simpler if RTs are assigned per VPN. For instance,
that document can state that one of the advantages is that when using
RT-constraint a single RT can express the VPN membership. I don't
believe this needs to be a "bis". But clarifying this point would be a
good thing. I'm sure the question will be posed again. It is the kind of
issue that is just bound to be raised periodically.

  Pedro.

---

From: Mach Chen <[email-masked]>
Date: Thu, 12 Nov 2009 09:20:43 +0800

Hi Russ,

> I

As said in my previous email, there is actually no confusion before 
RT-constrian being invented. The purpose of RT-constrain is to limit the 
unnecessay routes sending/receiving, if many restrictions have to be applied 
to the designing/operating, the restrictions will reduce the merits of 
RT-constrain, even more probably make RT-constrain un-deployable.

Best regards,
Mach

---

From: Mike Benjamin <[email-masked]>
Date: Fri, 13 Nov 2009 10:16:22 -0700

On Wed, Nov 11, 2009 at 02:40:41PM +0900, Robert Raszuk wrote:
: Jie,
: 
: >In most networks different
: >kind of VPNs are deployed gradually based on the demand of customers. Thus
: >it is impossible to make a plan for deployment of all kinds of VPNs at the
: >beginning. And this would also affect the flexibility of deployment of new
: >VPN services.
: 
: There is many years of operational experience in deployment of various 
: VPN services today. AFAIK non of the deployments today have found this 
: to be of any practical issue.
: 
: I think it would be great at this point to hear from operator's 
: community if they see a recommendation for unique RT assignment for 
: different customers/services as a problem.

The current RT method is the preferable method from our perspective.

Even if the possibility to re-use RTs based on AFI existed, we would
avoid using it for the sake of our operations teams.  To us the RT
represents a network, regardless of address type within that network.
If that network is IPv4 today and later wants to enable IPv6, we
expect it to exist within the same topology.  If our customer wants a
*different* network topology to exist for the new address family,
that is a different network, and now a different RT.

>From a design/scale perspective I can see this being slightly useful
to preserve memory where the topology does not require a route (read;
mixed v4/v6 network, but one PE does not handle any v4 connectivity),
but I see this more as a solution looking for a problem than anything.

As a service provider, I would not support its introduction.

--mikeb

: Thx,
: R.
: _______________________________________________
: Idr mailing list
: [email-masked]
: https://www.ietf.org/mailman/listinfo/idr

--
Mike Benjamin   -     +1-602-744-3403
[email-masked]  - Development Engineering
Global Crossing -       Phoenix, USA

---

From: "Deng, Guan" <[email-masked]>
Date: Mon, 16 Nov 2009 00:08:44 +0100

Hi Robert, Mike

I agree your opinion, it will confuse our Ops a great deal.

Guan

-----Original Message-----
From: [email-masked] on behalf of Mike Benjamin
Sent: Fri 11/13/2009 6:16 PM
To: Robert Raszuk
Cc: [email-masked]
Subject: Re: [Idr] Response to comments on generalized RT constrain solution

--mikeb

: Thx,
: R.

--

Kabel Deutschland bietet Ihnen Fernsehen, Internet und Telefonie aus einer Hand. Informieren Sie sich ueber unsere Produkte unter www.kabeldeutschland.de
Diese E-Mail und etwaige Anhaenge enthalten vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind, benachrichtigen Sie bitte den Absender und vernichten Sie anschliessend diese Mail und die Anlagen.

--

Kabel Deutschland GmbH
Betastr. 6-8
85774 Unterfoehring
Geschaeftsfuehrer: Dr. Adrian von Hammerstein, Erik Adams, Dr. Manuel Cubero del Castillo-Olivares, Paul Thomason
Vorsitzender des Aufsichtsrats: Prof. Dr. Heinz Riesenhuber
Handelsregister: Amtsgericht Muenchen HRB 145 837, Sitz der Gesellschaft: Unterfoehring

------------

Kabel Deutschland Vertrieb und Service GmbH & Co. KG
Betastr. 6-8
85774 Unterfoehring
Handelsregister: Amtsgericht Muenchen HRA 83902, Sitz der Gesellschaft: Unterfoehring
Komplementaerin: Kabel Deutschland Verwaltungs GmbH, Amtsgericht Muenchen, HRB 145 835, Sitz der Gesellschaft: Unterfoehring
Geschaeftsfuehrer: Dr. Adrian von Hammerstein, Erik Adams, Dr. Manuel Cubero del Castillo-Olivares, Paul Thomason

------------

Kabel Deutschland Breitband Services GmbH
Betastr. 6-8
85774 Unterfoehring
Geschaeftsfuehrer: Dr. Adrian von Hammerstein, Erik Adams, Dr. Manuel Cubero del Castillo-Olivares, Paul Thomason
Handelsregister: Amtsgericht Muenchen HRB 122 932, Sitz der Gesellschaft: Unterfoehring

------------

---

From: Jie Dong <[email-masked]>
Date: Tue, 17 Nov 2009 16:41:14 +0800

Hi Guan & Mike,
 
Thanks for your attention to this topic. I'm not quite sure what the "it"
means in your comments. I think some clarification here is needed. 
 
Generalized RT-constrain doesn't require any modification to the usage of
RT, but only to insure that even without elaborate planning of RT
allocation, operators will not encounter problems, such as receiving
unneeded VPN routes, or affecting existing networks, which may happen if
existing RT-constrain is used.
 
So this generalized RT-constrain will not restrict the behavior of
operators, in opposite it will relax the restriction on the planning of
different kinds of VPN services, thus could help operators in the deployment
of new VPNs. 
 
And please note that generalized RT-constrain supports IPv6 address
specified RT, which cannot be used with existing RT-constrain.

Best regards,
Jie

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Deng,
Guan
Sent: Monday, November 16, 2009 7:09 AM
To: Mike Benjamin; Robert Raszuk
Cc: [email-masked]
Subject: Re: [Idr] Response to comments on generalized RT constrain solution

Hi Robert, Mike

Guan

-----Original Message-----
From: [email-masked] on behalf of Mike Benjamin
Sent: Fri 11/13/2009 6:16 PM
To: Robert Raszuk
Cc: [email-masked]
Subject: Re: [Idr] Response to comments on generalized RT constrain solution

On Wed, Nov 11, 2009 at 02:40:41PM +0900, Robert Raszuk wrote:
: Jie,
:
: >In most networks different
: >kind of VPNs are deployed gradually based on the demand of customers.
Thus
: >it is impossible to make a plan for deployment of all kinds of VPNs at
the
: >beginning. And this would also affect the flexibility of deployment of
new
: >VPN services.
:
: There is many years of operational experience in deployment of various
: VPN services today. AFAIK non of the deployments today have found this
: to be of any practical issue.
:
: I think it would be great at this point to hear from operator's
: community if they see a recommendation for unique RT assignment for
: different customers/services as a problem.

--mikeb

: Thx,
: R.

-- 

Kabel Deutschland bietet Ihnen Fernsehen, Internet und Telefonie aus einer
Hand. Informieren Sie sich ueber unsere Produkte unter
www.kabeldeutschland.de
Diese E-Mail und etwaige Anhaenge enthalten vertrauliche und/oder rechtlich
geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind,
benachrichtigen Sie bitte den Absender und vernichten Sie anschliessend
diese Mail und die Anlagen. 

-- 

Kabel Deutschland GmbH
Betastr. 6-8
85774 Unterfoehring
Geschaeftsfuehrer: Dr. Adrian von Hammerstein, Erik Adams, Dr. Manuel Cubero
del Castillo-Olivares, Paul Thomason
Vorsitzender des Aufsichtsrats: Prof. Dr. Heinz Riesenhuber
Handelsregister: Amtsgericht Muenchen HRB 145 837, Sitz der Gesellschaft:
Unterfoehring 

------------ 

Kabel Deutschland Vertrieb und Service GmbH & Co. KG
Betastr. 6-8
85774 Unterfoehring
Handelsregister: Amtsgericht Muenchen HRA 83902, Sitz der Gesellschaft:
Unterfoehring
Komplementaerin: Kabel Deutschland Verwaltungs GmbH, Amtsgericht Muenchen,
HRB 145 835, Sitz der Gesellschaft: Unterfoehring
Geschaeftsfuehrer: Dr. Adrian von Hammerstein, Erik Adams, Dr. Manuel Cubero
del Castillo-Olivares, Paul Thomason 

------------ 

Kabel Deutschland Breitband Services GmbH
Betastr. 6-8
85774 Unterfoehring
Geschaeftsfuehrer: Dr. Adrian von Hammerstein, Erik Adams, Dr. Manuel Cubero
del Castillo-Olivares, Paul Thomason
Handelsregister: Amtsgericht Muenchen HRB 122 932, Sitz der Gesellschaft:
Unterfoehring 

------------