Le 21 oct. 2011 à 13:34, Maoke a écrit :
...
> 2011/10/21 Rémi Després <[email protected]>
...
> The PSID is WITHIN the /60 (at its end).
>
> to clarify: WITHIN the /60 means within the address block of the /60, not
> *within the first 60 bits*, (then at its end = starts from 61st bit), right?
It looks like we have a misunderstanding here, the origin of which I couldn't
find, but which I am sure we can resolve.
In the 4rd-addmapping draft:
- The PSID is at the end of the CE Generalized IPv4 prefix (Fig 3)
- The CE index is at the end of the CE Generalized IPv4 prefix (Fig 2)
- The CE index is at the end of the CE IPv6 prefix (within it)
Consequently, if CE IPv6 prefixes are /60s, PSIDs are in my understanding
"within the first 6O bits".
Extracts from the 4rd-addmapping draft:
- In Figure 2:
<----------------- at most 64 bits ------------------>
+-----------------------------------------------------+
| CE IPv6 prefix |
+-----------------------------------------------------+
: :
+--------------------------------+--------------------+
| Rule IPv6 prefix | CE index |
+--------------------------------+--------------------+
: :
+------------------+--------------------+
| Rule IPv4 prefix | CE index |
+------------------+--------------------+
: :
+---------------------------------------+
| CE Generalized IPv4 prefix |
+---------------------------------------+
<----------- at most 44 bits ---------->
- In Figure 3:
(C) CE Generalized IPv4 prefix having 33 to 44 bits
+--------------------------------------------------+
| CE Generalized IPv4 prefix |
+--------------------------------------------------+
: :
+-------------------------------------------+------+
| CE IPv4 address | PSID |
+-------------------------------------------+------+
<----------------- 32 bits -----------------><--.-->
|
max 12 bits
> The IPv6 /64 prefix to be used to reach a CE contains:
> 1) The Rule IPv6 prefix (that of the rule whose IPv4 prefix matches the IPv4
> destination)
> 2) The IPv4 suffix (that part of the IPv4 destination that follows the IPv4
> prefix of the matching rule)
>
> the CE IPv6 prefix = 1) + 2), right?
>
> 3) The PSID (whose length is known iff the matching rule specifies a CE
> IPv6-prefix length)
>
> the EA bits = 2) + 3), right?
Depending on what you call EA bits, it can be 2+3 or 2+3+4 in case of unknown
CE-prefix length by sources
>
> 4) If the PSID length is unknown, the "PSID complement" that completes the
> Max PSID.
> 5) A 0 padding if fields 1 to 4 don't reach 64 bits
>
> Note 1: If a Domain-IPv6-suffix option is used, the PSID length is
> necessarily known, and the PSID complement is then replaced by the Domain
> IPv6 suffix found in the matching rule. (ref draft-murakami-softwire-4rd-01.
>
> it seems to me that the draft-murakami-softwire-4rd-01 hasn't explain how do
> we use the "Domain IPv6 suffix", :(
Indeed.
That's why I wrote something about it in sec 5.5 of the 4rd-addmapping draft
version -00 (where it is called the "CPE-cascade" option).
That was based on explanations received privately from Tetsuya Murakami.
However, having received neither approval nor criticism from him, or from
anyone, I can't be sure it was accurate.
In version -01, we decided to consider the subject out of scope, to be
documented separately.
>
> Note 2: If ordinary CE IPv6 prefixes are /60s, the PSID complement has
> typically 4 bits (to fit in the /64).
> The only exception is if the sharing ratio needs to exceed 256, so that the
> PSID length exceeds 8. Then, the PSID complement of less than 4 bits.
>
>> on the other hand, there is a limitation. if c + m > 64, the above address
>> planning is not deployable, but with our effort of maximum compression,
>> we believe the undeployable case rarely happens for normal providers, right?
>
> Yes.
>
> The only impossibility is if the available IPv4 space is so small that no
> sharing ratio can be sufficient for the number of IPv4 shared addresses to
> equal the number of ordinary CE IPv6 prefixes.
>
> sure. in this case we can help nothing.
>
> If the above is still unclear (or bugged!), thanks for letting me know.
>
> Regards,
> RD
>
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
