Re: [Softwires] 4rd Address Mapping - version-01

[Jacni Qin <[e-mail]>]

hi,

On 10/17/2011 11:59 AM, Maoke wrote:
> hi Jacni,
>
> thanks a lot for the reply. please see inline.
>
> 2011/10/17 Jacni Qin <[e-mail] <mailto:[e-mail]>>
>
>     hi,
>
>     Let me try to answer your questions, please see below,
>
>     On 10/15/2011 10:14 AM, Maoke wrote:
>>     hi Remi and all,
>>     a discussion on the address mapping in -01.txt, trying to fully
>>     understand the design. comments are requested.
>>     - what if there are two rules?
>>       suppose we have 192.32../12 (0xc0200000/12, i think it's not
>>     the 0x602 as Leaf previously mentioned, ;-)
>>       and we also have 64.32../16 (0x40200000/16). we have a lot of CEs.
>>     Q1. if we use the two as the Rule_IPv4_Prefix_A and _B, can we
>>     map them to a single Rule_IPv6_Prefix?
>     Yes.
>
>
>>         Rule IPv6 Prefix: 20010db        (2001:db0::/28)
>>         CE1 IPv4 address:     c02 98765         (192.41.135.101)
>>                 CE1 PSID:              4
>>             CE1 CE index:         987654
>>     ---------------------------------------------------------------
>>     (1)  CE1 IPv6 prefix: 20010db 987654 (2001:db9:8765:4000::/52)
>>         suppose we happen to have another CE somewhere else:
>>         Rule IPv6 Prefix: 20010db
>>         CE2 IPv4 address:    4020 9876          (64.32.152.118)
>>                 CE2 PSID:             54
>>             CE2 CE index:         987654
>>     ---------------------------------------------------------------
>>     (2)  CE2 IPv6 prefix: 20010db 987654 (2001:db9:8765:4000::/52)
>>     ambiguity happens and packet encapsulated with the same CE IPv6
>>     address cannot be routed to the correct CE.
>     This is not gonna happen, since the IPv6 address planing must be
>     done natively considering nothing about the IPv4 in the very
>     beginning. In your example, I see you get a 2001:db0::/28 and you
>     want to assign a /52 to each CE, then ok, there will be 24 bits to
>     distinguish CEs and should be assigned continuously without any
>     conflict. The next step is to check the available IPv4 spaces we
>     have for the given number of subscribers, then based on which to
>     design the rules. You made it in an opposite direction.
>
>
> i understand what you mean is the following steps of rule_IPv6_prefix 
> decision:
> 1. list all the IPv4 addresses we have for the given number of 
> subscribers;
> 2. aggregate these IPv4 addresses into contiguous blocks, suppose that 
> you start from the point of minimum waste (no unused IPv4 addresses 
> are involved in the rules);
> 3. define the share-ratio and calculate the rule_IPv6_prefix for each 
> rule_IPv4_prefix defined in the step 2;
> 4. if your IPv6 space is far bigger to accommodate all the 
> rule_IPv6_prefixes, then go back to step 2 and try to make some relax 
> (trade-off), allowing unused IPv4 addresses involved in the rule to 
> some extent but gaining fewer rules.
>
> my example was, from beginning, making a fixed rule_IPv6_prefix and 
> two large IPv4 prefixes, where it is possible that a lot of actually 
> unused IPv4 addresses contained. does the "opposite direction" in you 
> context mean 1) i put CE index behind a predefined rule_IPv6_prefix, 
> or 2) i made large IPv4 prefixes as the start point?
I meant the latter one (not 100% ;-)). You can aggregate these IPv4 
prefixes into contiguous blocks, by for instance as you proposed, 
changing the sharing ratio of the second example (64.32../16), 4-bit 
PSID to 8-bit PSID to make a 24-bit CE index as the first example 
(192.32../12). The aggregation should be done through the design of Rule 
IPv6 prefixes. Pick a /27 which contains two /28, use the first /28 as 
the Rule IPv6 Prefix for 192.32../12, then the second /28 contains two 
/29, preserve the first /29, then the second /29 contains two /30 ..., 
finally pick a /32 as the Rule IPv6 Prefix for 64.32../16. Then the two 
rules share the same /27 and can be aggregated.

> for the point 2), i may assume that all the addresses inside these two 
> blocks are potentially used for our IPv4 subscribers and therefore 
> there is not waste, and i actually meant the same as you did. ;-)
>
>     We break the boundary between the IPv4 address and port, use the
>     bits (24 bits in the examples above) together to identify the
>     subscribers. The only reason I see to employ multiple IPv4
>     prefixes is we can't get a large enough one. Additionally, in the
>     second example above, you changed the sharing ratio to make a
>     "24-bit index", then you should change the Rule IPv6 prefix to,
>     for example /27, for the two IPv4 prefixes of "same size". On the
>     other hand, according to the consensus (if I get it correctly) of
>     the interim meeting, more than one sharing ratios for the extended
>     address case is not desirable, that flexibility should be offered
>     by stateful approaches.
>
>
> sorry, a little confused. do you mean that, if we have 192.32../12 and 
> 64.32../16 for the rule_IPv4_prefixes and we have the 4-bit PSID (me 
> too, don't desire to have more than one sharing ratios), then and we 
> need each CE IPv6 prefix as /52, then the rule_IPv6_prefixes for the 
> two rules should be /28 and /32, respectively, right?
Yes, and please see my comments above.

>
>>     therefore my answer to Q1, is NO, unless we carefully select IPv4
>>     addresses for CEs with giving up to use some of them, which have
>>     been so precious.
>>     Q2. then it must fine as long as we map them to different Rule
>>     IPv6 Prefix. (?)
>>         suppose CE1 is the same as (1). for 64.32../16, we use a
>>     longer stuff.
>>         however, there is a CE3:
>>       Rule IPv6 Prefix B: 20010db8       (2001:db8::/29)
>>         CE3 IPv4 address:    4020 1876   (64.32.24.118)
>>                 CE3 PSID:             54
>>             CE3 CE index: 987654
>>     ---------------------------------------------------------------
>>     (3)  CE3 IPv6 prefix: 20010db 987654 (2001:db9:8765:4000::/52,
>>     woops!)
>>     ambiguity happens. then we may argue: using the ugly
>>     Rule_IPv6_Prefix_B is the root of the problem! we have not to use
>>     a prefix covered by another.
>     No, I think the bits of the same position are not additive. So, it
>     should be a delegated prefix of "/53", right?
>
>
> :P sorry for the typo but i have pointed out in the errata. :P 
> however, even though this is /53, and you will have, in the route 
> table, both
>    2001:db9:8765:4000::/52 => route to CE1
>    2001:db9:8765:4000::/53 => route to CE3
>
> but for the packet encapsulated with the destination address 
> 2001:db9:8765:4000::200:5efe, you couldn't decide the route should go 
> to CE3 instead of CE1. here the longest-match doesn't work. right?
I guess the second delegated prefix should be 2001:db8:1876:5400::/53

>
>>     Q3. what does the exclusiveness of Rule IPv6 Prefix mean?
>>         if we have 2001:da0::/28 for the Rule_IPv6_Prefix, everyone
>>     will be happy. however, unfortunately, we have only one /28 IPv6
>>     aggregate. then what we have to do is splitting the /28 block
>>     into mutually exclusive pieces of small blocks. in the above
>>     example, if we have the following rule table:
>>         Rule_IPv4_Prefix Rule_IPv6_Prefix
>>        -----------------------------------
>>         192.32../12      2001:db0::/29
>>         64.32../16       2001:db9::/29
>>        -----------------------------------
>     Yes, the exclusiveness. It's similar to what we do to further
>     divide a subnet hierarchically. Hierarchies/exclusiveness avoid
>     conflicts but lose the efficiency of addressing. BTW, the /29
>     example is the same as what I propose above. :-)
>
>
> ok. the exclusiveness is cleared. thanks a lot for the help! then 
> please focus on the upper part further.
Great, we're on the same page.


Cheers,
Jacni

>
> thanks again and regards,
> maoke
>
>
>>         then it will work fine within the /28 room in total. for
>>     192.32../12, if the PSID is at least 4bit, then the *shortest* CE
>>     IPv6 prefix length is 29 + (32 - 12) + 4 = 53 now, rather than 52
>>     in the previous example. if we have only or want to use only at
>>     most a /44 IPv6 prefix for the residual deployment, for the above
>>     2 IPv4 networks, we are not able to safely deploy the CE prefix
>>     shorter than /64, no matter how we take the effort!
>>         Jacni once mentioned that if we have a /x IPv6 prefix while
>>     the "philosophy" of address planning decides to have /y for each
>>     CE-delegated network, then we can play the magic with the bits
>>     between the /x and the /y. i would like to point out here,
>>     because of the exclusiveness requirement, there is a hard
>>     limit for the power of the magic. if you have N IPv4 residual
>>     addresses, you must at least satisfy the condition:
>     Please see my comments above.
>
>
>     Cheers,
>     Jacni
>
>
>>         (4)     y - x >= log(N)
>>         when (4) is not true, cutting the rule into pieces does help
>>     almost nothing. i said "almost" because there is really a little
>>     we can achieve: there is really some IPv4 address seldom used for
>>     any routers, like 192.32.1.0. however, excluding such sort of
>>     addresses from the mapping scatters the mapping table into a huge
>>     number of /32-Rule_IPv4_Prefix and making the table size even
>>     longer than today's IPv4 routing table.
>>     just my 2 cents. execuse me if the humble calculation has any
>>     misunderstanding, and please point out without hesitation.
>>     best,
>>     maoke
>>     > 2011/9/22 Rémi Després <[e-mail]
>>     <mailto:[e-mail]>>:
>>     >> Alain, all,
>>     >>
>>     >> We have just posted a new version of our I-D on the proposed
>>     4rd Address Mapping.
>>     >> It is available at
>>     >> www.ietf.org/id/draft-despres-softwire-4rd-addmapping-01.txt
>>     <http://www.ietf.org/id/draft-despres-softwire-4rd-addmapping-01.txt>
>>     >>
>>     >> Our presentation will be based on THIS version, technically
>>     simpler than version -00.
>>     >> Major differences and their justifications will be briefly
>>     explained.
>>     >>
>>     >> Regards,
>>     >> RD
>>     >> _______________________________________________
>>     >> Softwires mailing list
>>     >> [e-mail] <mailto:[e-mail]>
>>     >> https://www.ietf.org/mailman/listinfo/softwires
>>     >>
>>     > _______________________________________________
>>     > Softwires mailing list
>>     > [e-mail] <mailto:[e-mail]>
>>     > https://www.ietf.org/mailman/listinfo/softwires
>>     >
>>
>>
>>     _______________________________________________
>>     Softwires mailing list
>>     [e-mail]  <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/softwires
>
>