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

Maoke <fibrib@gmail.com> Mon, 17 October 2011 03:59 UTC

Return-Path: <fibrib@gmail.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF89621F84ED for <softwires@ietfa.amsl.com>; Sun, 16 Oct 2011 20:59:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.048
X-Spam-Level:
X-Spam-Status: No, score=-3.048 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntasog9XDGqN for <softwires@ietfa.amsl.com>; Sun, 16 Oct 2011 20:59:24 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 36B9B21F84E5 for <softwires@ietf.org>; Sun, 16 Oct 2011 20:59:24 -0700 (PDT)
Received: by qyk34 with SMTP id 34so577234qyk.10 for <softwires@ietf.org>; Sun, 16 Oct 2011 20:59:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HdQIVzD2LZG+Byql+OwS7Tk7+yw2FOIXb7pfGP+JlRk=; b=d48ntlRZwUha9zGrAyQW2QFapFz0Kl9ukXZLchYuFiuc9lJud3NrsSDKkY4gtuLtJa 5WWSua4xmbr+UW7cbX07zwNBaUWTD1kRO/T4xzzcj7hjOEE0q3iW0c/pudPRaeBVD5O8 XYQcNAGuiPwCHQ+vFVB9Fj/kIcv1Y6HwCL5v0=
MIME-Version: 1.0
Received: by 10.229.63.169 with SMTP id b41mr3711657qci.145.1318823963651; Sun, 16 Oct 2011 20:59:23 -0700 (PDT)
Received: by 10.229.214.212 with HTTP; Sun, 16 Oct 2011 20:59:23 -0700 (PDT)
In-Reply-To: <4E9B9BC5.2090200@jacni.com>
References: <D8334AA7-5001-4A92-B977-CE32931F4197@laposte.net> <CAAuHL_Cm6WYiM2Cu-fmu=gBLgTYDZ6hr56BfcXMoeS=Af4Q_jw@mail.gmail.com> <CAFUBMqUvrP-s1yrJ0=ToAA_SvRLWQtq7JCTtpASNiS1GAxdSNQ@mail.gmail.com> <4E9B9BC5.2090200@jacni.com>
Date: Mon, 17 Oct 2011 12:59:23 +0900
Message-ID: <CAFUBMqUS1cATWr07Os4d6aLUbNaVwuOCcthObOiMPuDv8VfU1g@mail.gmail.com>
From: Maoke <fibrib@gmail.com>
To: Jacni Qin <jacni@jacni.com>
Content-Type: multipart/alternative; boundary="0016e65da6eedfef8204af76a17c"
Cc: Softwires-wg <softwires@ietf.org>
Subject: Re: [Softwires] 4rd Address Mapping - version-01
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Oct 2011 03:59:26 -0000

hi Jacni,

thanks a lot for the reply. please see inline.

2011/10/17 Jacni Qin <jacni@jacni.com>
>
> 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 <despres.remi@laposte.net>:
> >> 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
> >> Softwires@ietf.org
> >> https://www.ietf.org/mailman/listinfo/softwires
> >>
> > _______________________________________________
> > Softwires mailing list
> > Softwires@ietf.org
> > https://www.ietf.org/mailman/listinfo/softwires
> >
>
>
>
>
> _______________________________________________
> Softwires mailing listSoftwires@ietf.orghttps://www.ietf.org/mailman/listinfo/softwires
>
>