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.
Nonetheless, you have brought up a good point that deserves further 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