Scott Brim wrote:
The idea for this is that the EID, while not announced globally, is still globally scoped.Excerpts from Brian Dickson on Wed, Jan 02, 2008 08:30:18PM -0500:What if the EIDs were (assigned | issued) as PI address blocks? Specifically, PI blocks not routed into the DFZ, per se (but potentially available as an "upgrade path"), as an alternative to ULA or ULA-{C|G}. The concept is to "map-and-map", from PI-EID to PA-RLOCs, via 1:1 mapping(s). The reverse mappings are likewise 1:1, reasonably trivial, and essentially unchanging regardless of RLOCs in use. The real benefit is that, like SIIT, it is feasible to do ICMP transliteration, thus support PMTUD and similar activities. That, and not affecting the PMTU itself in the first place. :-) The map-and-map effectively becomes NAT + SNAT, without any port mangling.So ... setting terminology aside, you're suggesting a 1:1 relationship between an aggregatable, globally routed address and a locally scoped,not necessarily aggregatable address?
This is so that it is possible for end-sites to move in, out, or between, EID space and DFZ space,
as they grow, shrink, or move.And on the RLOC:EID side, it's more of a N*(1:1) relationship, where N varies by EID block,
as well as over time, including which specific RLOC blocks are used per EID.
If I understand you correctly, why have that kind of mapping at all? Why not do something like 8+
It's a question of flexibility and scope.It's almost exactly analogous to the major problems with TLA/NLA from an operator perspective.
There is no need to impose additional structure, beyond the existence of prerequisites for use of the technology. Imposing any fixed structure, universally, is very likely to be universally opposed (and rightly so) by v6ops folks.
The idea is that RLOC space is arbitrarily subnetted by LIRs, in whatever VLSM scheme they need, and that
the size and number of end-assignments is also arbitrary.EID end-sites would clearly best benefit from having all RLOC blocks be the same size, but as long as the EID end-site is able to operate from within some smallest-common-denominator block, all is good.
The main benefit I see, is that the EID site is able to entirely control the admistration and operation of the ITR/ETR, if they want, without needing any or all of their upstream providers to do anything more than assign PA blocks to them.
I'm sure both the ISP and the EID site would be very happy to have that as one possible arrangement, even if it is also possible for the EID site to out-source operation of the xTRs to any third party, including the ISP.
Brian -- to unsubscribe send a message to rrg-request@psg.com with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg