Hi Fred, > > What happens when the EID needs to change its RLOC (for provider > > independence), > > Changing the RLOC obviously changes the EID prefix. Those > who are lucky enough to have provider-independent RLOCs > will not have a problem with this. Those that don't would > incur a site-wide renumbering event if they changed > providers. But, the goal here is to support automatic mapping > between core DFZ routers with public IPv4 addresses that > would presumably be stable; we would not want this scheme > to penetrate deeply beyond the core DFZ routers, and would > instead use some stateful map/encaps scheme within end sites.
One of the major goals for id/locator split is to make the identifier provider-independent. Embedding the RLOC in the EID will damage this goal. > > or use multiple RLOCs (for multihoming)? > > The proposal is that multiple site border routers would > configure the same IPv4 RLOC in anycast fashion to give > multihoming. Another name that someone suggested for > this scheme was "multihomed 6to4" For a multi-homed site, its multiple border routers should use the same IPv4 RLOC in anycast fashion. It means each multi-homed site should be allocated a unique RLOC. I wonder whether such kind of RLOC is still topologically aggregatable in provider networks. Xiaohu > > The whole point of 'separation of location and identity' is that it > > requires a binding. TANSTAAFL. > > The major point to be made is that there are different > considerations within different domains of application. > Instead of saying "TANSTAAFL", I would rather say "there > is no one size fits all". > > So, stateless mapping using 6to4++ within the core where > addresses are more stable, and stateful mapping nearer the > edges where addresses are more volatile is what is being > proposed here. > > Fred > [email protected] > > > > > Noel > _______________________________________________ > rrg mailing list > [email protected] > http://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
