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

[Robert Raszuk <raszuk at cisco.com>]

Hi Jie,

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

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.


> 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