hi Jacni, thanks a lot for the reply. please see inline.
2011/10/17 Jacni Qin <[email protected]> > > 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? 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? > > 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? > > 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. 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 <[email protected]>: > >> 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 > >> > >> 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 > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/softwires > >> > > _______________________________________________ > > Softwires mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/softwires > > > > > > > _______________________________________________ > Softwires mailing > [email protected]https://www.ietf.org/mailman/listinfo/softwires > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
