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

[Mach Chen <mach at huawei.com>]

Hi Robert,

Fogive me to chime in.

Please see inline...

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

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.

> 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.
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.
>
> Of course between different customer's VPNs you need different RT values 
> but this is basic provisioning requirement for BGP VPNs application.
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.

> > 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 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.
> In worst case the consequence of splitting RT space may result in 
> 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.
> > 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 ?

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.

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

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

> 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
>
> _______________________________________________
> Idr mailing list
> Idr at ietf.org
> https://www.ietf.org/mailman/listinfo/idr