Re: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation

[Jacni Qin <[e-mail]>]

hi,

On 10/10/2011 4:40 PM, Maoke wrote:
> hi Jacni,
> thanks for the discussion from the view of address planning. it is 
> clear. i just would like to add an overview comment on the "philosophy".
> to my understanding, the prefix length to a customer depends upon, 
> essentially, how many end-system identifiers are needed, according 
> to what we estimate, within the scope of the customer network. in the 
> age of IPv4, the estimation is typically expressed with a definite 
> prefix length because we hardly have a shorter one than what we really 
> need. in the age of IPv6, however, if the prefix length for a customer 
> network in address planning is not a fixed value but a range with 
> relaxation, the art of address planning may also change. (e.g., 
> the block assigned to a subscriber is at most /60 supporting up 
> to 1M subscribers in total, and at least /72 in oder to support up 
> to 2^56 end-system identifiers within each CE-delegated network). with 
> this in mind, ISP may have larger room to pick up techniques and 
> deployment tactics possibly without doing less-necessary tradeoffs.
Thanks for your comments, I was only guessing based on experiences from 
IPv4. And yes, as you mentioned, something will change in IPv6.
While I think in practice, from ISP's perspective, probably there won't 
be that much flexibility, for example, there can't be too many SLAs.
Anyway, we can only know that after IPv6 comes true. ;-)


Cheers,
Jacni

> the same philosophy doesn't imply a unique art of action. MHO. sorry 
> but out of the scope of this group.
> thanks a lot,
> maoke
> 2011/10/10 Jacni Qin <[e-mail] <mailto:[e-mail]>>
>
>     hi,
>
>     One comment on the example you proposed, please see below,
>
>     On 10/9/2011 7:30 PM, GangChen wrote:
>>     ...
>>     I'm not sure what formula you have to deduce this *requirement*.
>>     Different sharing ratios should implicitly be expressed by different
>>     IPv6 prefix lengths when an operator would deploy PD. At this point,
>>     you can't help even you encode whole IPv4 address in suffix. As for
>>     the question you raised, I think that are operational issues more than
>>     technical issues. I take your example as explanation for your better
>>     understanding.
>>
>>     A small ISP has its Rule IPv4 prefix such as 10/8, while its total
>>     IPv6 block has fairly long prefix like /48 or a /56.
>>
>>     Then an operator could strategically pre-config a relatively small
>>     IPv4 subnet to 4v6 domain as rule IPv4 prefix, like 10/24. Then you
>>     could get more space in IPv6 prefix to put PSID information. See that
>>     is quite flexible if you do have a good operational planning.
>>
>     I get it, but let me try in another way.
>     The IPv6 addressing must not be affected, that's one of the basic
>     objectives of MAP we'll agree on, right?
>
>     So, firstly the IPv6 address planning should be done natively
>     according to the service requirements, the expected scale of
>     subscribers, and the address space assigned respectively.
>     For example, if you plan to assign a /60 to each subscriber in a
>     given domain with 1M subscribers totally, an IPv6 prefix of "/40"
>     is required (probably shorter given the efficiency loss of
>     hierarchical aggregation).
>     Then, this becomes the assumption (or restriction) on which we've
>     got 20 bits space to play with our art.
>
>     The next step is to decide the sharing ratio, say, 2k ports per
>     subscriber, the PSID will be of 5 bits. Here the tradeoff is to
>     use how many bits borrowed from ports or from the first 32 bits.
>     Then in this case, an IPv4 prefix of "/17" is required to
>     accommodate the 1M subscribers (through "15+5").
>     If we're lucky to get a block of "/17", one piece of MAP rule is
>     enough. Otherwise, we'll have to face another tradeoff, smaller
>     number of rules or smaller number of fragmented blocks used.
>
>     ISPs' cases are quite different, while the philosophy of address
>     planning is not, and should be kept in mind when we design the MAP.
>
>
> Cheers,
> Jacni
>
>