Subject: Re: [Softwires] draft-despres-softwire-4rd-addmapping

From: Rémi Després <[email-masked]>
Date: Mon, 12 Sep 2011 18:04:54 +0200

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-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>