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

[Jie Dong <[e-mail]>]

Hi Robert,

Thanks for your prompt reply.

Yes, I have been pointing out that using the same RT for VPNv4 and VPNv6
should be encouraged. But this should not be restricted to congruent
topologies. For management simplicity and less configuration of different
RTs, using the same RT for non-congruent topologies of the same customer can
also be preferred. The most common scenario is customer's migration from
IPv4 to IPv6, and not all the sites need to migrate to IPv6 at once. 

As described in the draft, using different RT is one alternative solution,
but requires more configurations and in some scenarios will meet the problem
of difficulty in planning and management. Details are specified in section
6.2.1 of draft-dong-idr-vpn-route-constrain-01.

In addition, some VPN mechanisms propose generating RTs automatically, which
would makes planning and management of unique RT more difficult, and can
result in the same RT used by different VPN services. This draft is trying
to facilitate the deployment of new VPN services and avoid potential
problems.

Further discussions are always welcome. We especially solicit comments and
feedbacks on this from ISPs who has deployed or plans to deploy RT-Constrain
in their networks.

Many thanks.


Best Regards,
Jie

> 
> > Thus we just try to make RT-Constrain compliant with normal BGP.
> 
> Let me observe that RT-Constrain as documented in RFC 4684 is very
> complaint with normal BGP (modulo your definition of "normal BGP").
> 
> It needs to be pointed out that vast majority of customers would
> have valid requirement for congruent IPv4 and IPv6 topologies. So using
> the same value for those VPNs is not only possible, but also highly
> encouraged. Authors of RFC4684 looked at route-target as marker
> identifying a customer VPN of any address family.

> For possible migrations scenarios yes PE would be receiving both v4 and
> v6 VPN routes if the same RT is configured on both address families. If
> this turns to be an issue for some VPNs using during migration or even
> long term configuration of different RT values solves the issue.

> So I really do not think that we need to incorporate any protocol
> modifications here.