Re: [Idr] Discussions about RT-Constrain //RE: IETF-78 IDR minutes

[Robert Raszuk <[e-mail]>]

Hi Jie,

I think very careful RT allocation planning is needed in each 
multi-service network and this is regardless of rt-constrain use or not.

If you expect RT collisions to happen then I don't think prepending 
AFI/SAFI to an RT will be of any help.

You would be much better to propose modifications to the RT format 
itself to accomodate service encoding as part of it's value. Then 
automatically any protocol which uses RTs will inherit it.

But I don't think this is practically sound required, but clearly you 
have a different opinion. And I don't think AFI/SAFI+RT that much is 
needed. Providers usually already have their own ways to divide RT 
spaces among their services today just playing with available 8 octets.

If you think 8 octets is not enough maybe proposing 9 or 10 would 
address your concern of overlapping RTs for various types of VPNs.

 > RTs used in one type of VPN SHOULD be independent with any other
 > types of VPNs.

That would not generally not be a good practice. Perhaps for few 
migrations cases, but clearly not for long term deployment plan.

If you separate unicast from multicast the latter may have not work too 
well as it depends on unicast for it's RPF check. If you separate v4 
from v6 and sites that have a dual stack routing congruency requirement 
will just double the advertisement of RTs.

Cheers,
R.

> Hi Robert,
>
> Some further thoughts...
>
> Avoiding propagation and processing of unnecessary VPN routes is one
> important aspect. In addition, what we concern more is: with current
> RT-constrain mechanism [RFC4684] which uses one AFI/SAFI for all kinds of
> VPN services (including L3VPN, L2VPN, L1VPN, MVPN, and potential
> xxxVPNs...), configuration/deployment of one type VPN may affect other
> deployed VPNs in the network.
>
> As I said in my previous mail, such impact among different types VPNs can be
> more serious with more and more types of VPNs deployed in the network, and
> coexistence of static configured RT and automatic generated RT makes the RT
> collision among different types of VPNs much easier to occur, and it would
> become more and more difficult in planning and management of different types
> of VPNs when RT-constrain is deployed.
>
> RTs used in one type of VPN SHOULD be independent with any other types of
> VPNs. Thus it's straightforward and reasonable for RT-constrain to separate
> RT membership information of different AFI/SAFIs, which is what we proposed
> in our draft
> (http://tools.ietf.org/html/draft-dong-idr-vpn-route-constrain-01.txt).
>
>
> Best regards,
> Jie
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Robert Raszuk
>> Sent: Tuesday, September 07, 2010 2:05 AM
>> To: [e-mail]
>> Cc: [e-mail]
>> Subject: Re: [Idr] Discussions about RT-Constrain //RE: IETF-78 IDR
> minutes
>>
>> Hello Zhenqiang,
>>
>> Many thx for your email. I have no doubt about your deployment case. In
>> fact I think what you are planning to do does make sense.
>>
>> But let's do not forget about the overall picture. RT-constrain's
>> primary objective was to help automate inter-as VPNs. Later we have
>> observed that it may also help to allow to store on RRs only those set
>> of routes which are desired. The fact that it allows limit the amount of
>> automated inbound filtering on the PEs is more or less the over all
>> positive side effect :)
>>
>> So RT-constrain in itself is an optimization. This draft would be an
>> optimization to the optimization.
>>
>> Reg the impact of IPv6 introduction how many VPN IPv6 routes are you
>> concerned with ? Note that there are production IPv4 deployments with
>> over 1 million IPv4 routes today and without rt-constrain deployed at all.
>>
>> Are you concerned with the need to drop unnecessary routes on inbound RR
>> ->  PE (which is a very cheap operation) on those PEs which do not need
>> them ? Or are you under impression that all PEs would need to store
>> those routes even if those would not be needed .. the latter would be
>> very easy to address without any protocol changes by your favorite BGP
>> implementation.
>>
>> Many thx,
>> R.
>>
>>
>>> Hi Robert and Jie,
>>>
>>> I am Zhenqiang Li from China Mobile. I think this draft is useful. We
>>> are now planning the IPv6 migration scheme. During the migration
>>> period, some sites of a specific service will introduce IPv6 first.
>>> These IPv6-enabled sites (still support IPv4) need to communicate
>>> with other sites belonging to this specific service, including both
>>> IPv6-enabled and IPv4-only sites. Because they are parts of one
>>> service, we want them to be in one VPN. Thus we give the IPv6 route
>>> the same RT as the IPv4 route of this service. By using the proposed
>>> scheme in this draft, we can control the IPv6 route distribution
>>> within the IPv6-enabled sites. This is also helpful to limit the
>>> potential impact of IPv6 introduction.
>>>
>>> Best Regards, Zhenqiang Li
>>> _______________________________________________ Idr mailing
>> list
>>> [e-mail] https://www.ietf.org/mailman/listinfo/idr
>>>
>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>
>