Hi, Nejc,
Thanks for your detailed review.
Sorry for the late answer.
More in line.
Le 23 août 2011 à 15:00, Nejc Škoberne a écrit :
> Dear authors,
>
> I have some comments on your draft.
>
> ---------------------------------------------------------------------------
> 3. Terminology
>
> <snip>
>
> 4rd IID prefix: A 32-bit value use to disambiguate what
> concerns the 4rd address mapping from other
> address mapping that may coexist it the same
> AFTRs or CPEs, e.g. with dynamic port
> assignments.
>
> [NS: It would be nice if you defined what IID stands for. I guess it is
> "Interface ID"?]
It will be done in the next version, thanks.
> <snip>
>
> 5.3. Mapping from IPv4 address or A+P to IPv6 address
>
> <snip>
> For tunnel-based solutions (encapsulation or double-translation
> based),
>
> [NS: I think we have a terminology problem here. I think double-translation
> is not tunnel-based solution, since there is no encapsulation. See below
> for further discussion on this.]
See below.
> <snip>
> proposed to IANA for the 4rd IID prefix is 200:5efe::/32. It has bit
> 6 of its first octet set to 1, in order to indicate a universal scope
> of the IID ("u" bit of). Its other bits have, like in [RFC4214],
> IANA OUI in modified EUI format (ref. [RFC4291]).
>
> [NS: I guess there is a word missing in the parentheses ("u" bit of ??)?]
"of [RFC4291]", thanks.
> <snip>
>
> 5.4. Algorithmic Derivation of a Port Set from a Port-Set ID
>
> The port set specified by an
>
> [NS: Unfinished sentence?
Will be fixed, thanks.
> As I can see, the port-set derivation algorithm
> has changed.
> It would be nice to see the motivation why to use this particular
> algorithm, so to maybe describe its properties and state why they are
> important. For example, why do we need to reverse those bits in step [B](1)
> in Figure 4?
The reason is the combination of:
- Flexible sizes of CPE-assigned port sets (sec. 4.6.1)
- No per-customer states
. in BRs (ease of administration)
. in CPE's (for direct CPE-CPE routes - sec. 4.4)
> Also, it is not clear to me what is the "yyyy" part of the
> pattern. Why is it separated from the x-es? Finally, it would be great to
> show a short table of an example port-pairs obtained using this algorithm.]
> ---------------------------------------------------------------------------
A simpler presentation could be:
|0 14|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x x x x| R-PSID|x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
With ports 0-4095 excluded
Agreed?
> Other than that, a few more general comments:
>
> 1. Terminology
> --------------
>
> I think there is confusion regarding to use of terms tunneling and
> encapsulation. After some research, I would define the terms as follows:
>
> - Encapsulation. A process of wrapping a packet in another header of the
> same or different network protocol. Decapsulation is therefore the process
> of stripping off the outmost header of the encapsulating packet, which
> brings us back to the encapsulated packet.
>
> - Tunneling. A process of encapsulation, transmission and decapsulation
> of a packet.
>
> So again, double-translation has nothing to do with tunneling. In spirit of
> this, I would revise all occurencies of words "tunnel"/"tunneling" and
> "encapsulation" in the draft.
The problem will be avoided in the next version by not saying that
double-translation is particular case of tunneling.
> 2. Separating the mapping mechanism from the port-set calculation algorithm
> ---------------------------------------------------------------------------
>
> I would say that the address mapping described in the draft is somewhat
> orthogonal to the port-set calculation algorithm also proposed. The same
> goes for other stateless solutions, so I suggest, that we try to put all
> these algorithms into a separate document.
>
> As far as I am aware, the following algorithms have been officially proposed:
>
> a) Sequential method: port-set is a range of consecutive ports. (See
> I-D.matsuhira-sa46t-spec-03.)
>
> b) Modulo method: port-set for 1st CPE is (0, N, 2*N, ...), port-set for
> 2nd CPE is (1, N+1, 2*N+1, ...) and so on, where N is the number of CPEs
> sharing the same IPv4 address. (See I-D.xli-behave-divi-03.)
>
> d) "New 4rd method" (interleaved port-pairs): port-set for the 1st CPE is
> (0, 1, 2*N, 2*N+1, 4*N, 4*N+1, ...), where N is the number of CPEs
> sharing the same IPv4 address. (See
> I-D.despres-softwire-4rd-addmapping-00.)
>
> d) "Old 4rd method" (interleaved port-ranges of different sizes): port-set
> for the 1st CPE is:
> ([4k..4k/N], [8k..8k/N], [16k..16k/N], [32k..32k/N]),
> for the 2nd CPE is:
> ([4k+4k/N..4k+2*4k/N], ..., [32k+32k/N..32k+2*32k/N]),
> where N is the number of CPEs sharing the same IPv4 address. (See
> I-D.murakami-softwire-4rd-00.)
>
> e) Random method: port-set is a randomly chosen subset of all available ports.
> (See I-D.boucadair-pppext-portrange-option-07.)
>
> f) Port-range-mask method: port-set is a range of consecutive ports or a
> set of ranges of consecutive ports. (See
> I-D.boucadair-pppext-portrange-option-07.)
>
> If I forgot something, please let me know. It would be also nice to compare
> all these algorithms and to identify the trade-offs. The mechanism drafts
> would
> then just pick one of these algorithms (without the need to define it again)
> and justify the decision for the specific algorithm.
>
> What do you think about this proposal? With my colleagues we are preparing
> another port-selection algorithm, which would enhance the security for
> stateless solutions. Something like a stateless-ready counterpart to the
> Random method, specified in I-D.boucadair-pppext-portrange-option-07. This way
> we could just add such an algorithm to this "algorithms document" and the
> IPv4 address sharing mechanism document authors could then choose the one
> which suits them best.
Hopefully, we can succeed to standardize only one.
Authors of 4rd-addmapping intended to cover all known design objectives that
were found to be significant, with the view to build a good candidate for the
final choice.
Simplifying the presentation is an ongoing task.
Regards,
RD
>
> Thanks,
> Nejc
> _______________________________________________
> Softwires mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/softwires
>
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
