Subject: Re: [Softwires] MAP documents - next steps

From: Mark Townsley <[email-masked]>
Date: Wed, 1 Feb 2012 15:13:42 +0100

While I appreciate the functional modularity in understanding the solution space, I do wish that DT had come up with a way to make this one document to present to the world rather than four. I fear organ rejection when tossing a list of RFCs for one function to the CPE industry. 

In current form, each document has more or less than 10 pages of substantive text, with considerable overlap between them (how many "framework" and "architecture" sections do we really need for what are really just two variants of something 95% the same?). As further evidence of the problem, there are no less than 19 references to mdt-softwire-mapping-address-and-port from draft-mdt-softwire-map-translation-00. One page has 5 references alone. It's is like reading a single book with every other page in a different binding. 

Could we not eliminate the overlap, and just boil this down to one less than 40 page document? In fact, I bet if you tried you could get it down to half that. Looks like Remi's new document is on the right track in this regard. 

I'm in favor of the chairs stating that we will adopt a WG document based on the text in these documents, but I would like to see a stipulation that they be combined into one (perhaps two but with only the DHCP option separate) and the overlap eliminated among MAP, T and E eliminated. 

- Mark

On Jan 30, 2012, at 12:31 PM, Ole Trøan wrote:

> hi,
> 
> the MAP (Mapping of address and port) design team has now written and published the following sets of drafts.
> 
> the base document (port mapping algorithm):
>  http://tools.ietf.org/html/draft-mdt-softwire-mapping-address-and-port-03
>  http://tools.ietf.org/rfcdiff?url2=draft-mdt-softwire-mapping-address-and-port-03.txt
> 
> the encapsulation document (MAP-E):
>  http://tools.ietf.org/html/draft-mdt-softwire-map-encapsulation-00
> 
> the translation document (MAP-T):
>  http://tools.ietf.org/html/draft-mdt-softwire-map-translation-00
> 
> the DHCP option (MAP-DHCP):
>  http://tools.ietf.org/html/draft-mdt-softwire-map-dhcp-option-02
> 
> there is a MAP deployment document coming soon.
> 
> the solution described in this set of documents, are written to satisfy the following from the softwires charter:
>   4. Developments for stateless legacy IPv4 carried over IPv6 
>      - develop a solution motivation document to be published as an RFC 
>      - develop a protocol specification response to the solution 
>        motivation document; this work item will not be taken through 
> 
> in the design team's view, this set of documents are ready to be adopted as working group documents.
> 
> comments?
> 
> for the MAP design team,
> Ole
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Ole Trøan <[email-masked]>
Date: Wed, 1 Feb 2012 15:33:51 +0100

Mark,

> I'm in favor of the chairs stating that we will adopt a WG document based on the text in these documents, but I would like to see a stipulation that they be combined into one (perhaps two but with…

with regards to document organization we've been over that a few times. my understanding of the Beijing interim meeting was to have the organization of documents we have now. largely because there were discussions on different document status for the different documents. e.g. experimental versus standards track.

yes, it is certainly possible to merge the 3 documents (MAP, T, E), with separate sections that only apply to encapsulation and some that apply to translation. what I feat is that you will pollute the text with lots of "does not apply in the translation case", "fragmentation issues are slightly different", and so on.

this is obviously something the working group has to decide on, but I don't think that needs to be done before adopting this document set.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Wed, 1 Feb 2012 17:42:47 +0100

> I'm in favor of the chairs stating that we will adopt a WG document based on the text in these documents, but I would like to see a stipulation that they be combined into one (perhaps two but with…

Well, this seems similar to taking the new 4rd document and analyzing what is missing or is unnecessary.

Except for the fact that double RF46145 is replaced by the self-contained Header mapping variant, more transparent, but about which there is an ongoing discussion with Maoke, the last 4rd-U draft is, in my understanding, largely what you are looking for.

It avoids all the complexity of GMA port-mapping, a nice piece of technology but near to 5 pages that don't seem to serve real needs (a fixed PSID is enough in practice AFAIK). 

Avoiding to review the unified draft because of some NIH syndrome would be IMHO a way to miss a good opportunity for progress.

I do look forward to technical comments on draft-despres-softwire-4rd-U.

RD

---

From: Maoke <[email-masked]>
Date: Thu, 2 Feb 2012 12:38:26 +0900

2012/1/30 Ole Trøan <[email-masked]>

> the solution described in this set of documents, are written to satisfy
> the following from the softwires charter:

support. and the set becoming WG document will help the deployment guidance
drafting.

- maoke

---

From: Maoke <[email-masked]>
Date: Thu, 2 Feb 2012 13:20:55 +0900

2012/2/2 Rémi Després <[email-masked]>

>
> Except for the fact that double RF46145 is replaced by the self-contained
> Header mapping variant, more transparent, but about which there is an
> ongoing discussion with Maoke, the last 4rd-U draft is, in my
> understanding, largely what you are looking for.
>

briefly summary my action and understanding in order to avoid confusion. 1.
my detailed re-study on RFC6145 behavior in double translation has been
finished and i have NO new protocol or algorithm proposal which is worthy
sharing to the community; 2. (because) RFC6145 has provided (not thorough
but) good enough transparency when used in double translation, and
accordingly it is NOT needed to be updated; 3. carrying ICMPv4 directly in
IPv6 payload will be a harmful idea and less feasible.

basically i doubt it is significant enough to make a document explaining
the RFC6145 behavior in double-translation, as well as the corresponding
concerns. however, if some people would like to have such an informational
document, i'd love to elaborate.

- maoke

---

From: Rémi Després <[email-masked]>
Date: Thu, 2 Feb 2012 09:06:07 +0100

Le 2012-02-02 à 05:20, Maoke a écrit :

> briefly summary my action and understanding in order to avoid confusion.

> 1. my detailed re-study on RFC6145 behavior in double translation has been finished and i have NO new protocol or algorithm proposal which is worthy sharing to the community;

No misunderstanding on this.

> 2. (because) RFC6145 has provided (not thorough but) good enough transparency when used in double translation, and accordingly it is NOT needed to be updated;

Full transparency, based on clear theory, remains AFAIK better than "good enough" based on some collected statistic at a given time.

> 3. carrying ICMPv4 directly in IPv6 payload will be a harmful idea and less feasible.

I don't see where you see that ICMPv4 payload tunneled in a mapped header isn't easily feasible.

Stating it is harmful is of course not a proof.
Discussion on this point can continue with more details in other e-amils based on configurations you have in mind.  

RD

> basically i doubt it is significant enough to make a document explaining the RFC6145 behavior in double-translation, as well as the corresponding concerns. however, if some people would like to have such an informational document, i'd love to elaborate. 
> 
> - maoke

---

From: Maoke <[email-masked]>
Date: Thu, 2 Feb 2012 18:27:57 +0900

>
>
> 2. (because) RFC6145 has provided (not thorough but) good enough
> transparency when used in double translation, and accordingly it is NOT
> needed to be updated;
>
>
> Full transparency, based on clear theory, remains AFAIK better than "good
> enough" based on some collected statistic at a given time.
>

as i stated, we want to have better transparency but only if it is not
costly and the solution has no other obvious flaws.

> I don't see where you see that ICMPv4 payload tunneled in a mapped header

not feasible in term of supporting the operation where the single/double
translations are needed simultaneously and are needed to be treated
statelessly.

> Discussion on this point can continue with more details in other e-amils
> based on configurations you have in mind.
>

i have proposed a concrete problem rather than a simple statement at least
twice in the past mail dialogues. ;-)

- maoke

---

From: Xing Li <[email-masked]>
Date: Fri, 03 Feb 2012 10:12:58 +0800

> this is obviously something the working group has to decide on, but I don't think that needs to be done before adopting this document set.

I agree with Ole.

Regards,

xing

---

From: Congxiao Bao <[email-masked]>
Date: Sat, 4 Feb 2012 10:43:52 +0800

I support to have this set of drafts adopted as WG documents.

Congxiao

2012/2/3 Xing Li <[email-masked]>

>> While I appreciate the functional modularity in understanding the
>>> solution space, I do wish that DT had come up with a way to make this one
>>> document to present to the world rather than four. I fear organ rejection
>>> when tossing a list of RFCs for one function to the CPE industry.
>>>
>>> In current form, each document has more or less than 10 pages of
>>> substantive text, with considerable overlap between them (how many
>>> "framework" and "architecture" sections do we really need for what are
>>> really just two variants of something 95% the same?). As further evidence
>>> of the problem, there are no less than 19 references to
>>> mdt-softwire-mapping-address-**and-port from draft-mdt-softwire-map-**translation-00.
>>> One page has 5 references alone. It's is like reading a single book with
>>> every other page in a different binding.
>>>
>>> Could we not eliminate the overlap, and just boil this down to one less
>>> than 40 page document? In fact, I bet if you tried you could get it down to
>>> half that. Looks like Remi's new document is on the right track in this
>>> regard.
>>>
>>> I'm in favor of the chairs stating that we will adopt a WG document
>>> based on the text in these documents, but I would like to see a stipulation
>>> that they be combined into one (perhaps two but with only the DHCP option
>>> separate) and the overlap eliminated among MAP, T and E eliminated.
>>>
>> with regards to document organization we've been over that a few times.
>> my understanding of the Beijing interim meeting was to have the
>> organization of documents we have now. largely because there were
>> discussions on different document status for the different documents. e.g.
>> experimental versus standards track.
>>
>> yes, it is certainly possible to merge the 3 documents (MAP, T, E), with
>> separate sections that only apply to encapsulation and some that apply to
>> translation. what I feat is that you will pollute the text with lots of
>> "does not apply in the translation case", "fragmentation issues are
>> slightly different", and so on.
>>
>> this is obviously something the working group has to decide on, but I
>> don't think that needs to be done before adopting this document set.
>>
>
> I agree with Ole.
>
> Regards,
>
> xing
>
>
>
> cheers,
>> Ole
>> ______________________________**_________________
>> Softwires mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/softwires<https://www.ietf.org/mailman/listinfo/softwires>
>>
>>
>
> ______________________________**_________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/softwires<https://www.ietf.org/mailman/listinfo/softwires>
>

---

From: Wojciech Dec <[email-masked]>
Date: Sat, 4 Feb 2012 18:23:39 +0100

Fully agree with Ole.
We've been back and forth on the one-draft, many-drafts, too-many-drafts
discussion so many times, and it's not productive. We have a broad group of
individuals who are interested in pursuing the drafts. Given that this is a
WG that is meant to operate for its participants, as opposed to against
them (as has been the case), having progress in the form of document
adoption would be a good step forward.

-Woj.

On 1 February 2012 15:33, Ole Trøan <[email-masked]> wrote:

> mdt-softwire-mapping-address-and-port from
> draft-mdt-softwire-map-translation-00. One page has 5 references alone.
> It's is like reading a single book with every other page in a different
> binding.
> >
> with regards to document organization we've been over that a few times. my
> understanding of the Beijing interim meeting was to have the organization
> of documents we have now. largely because there were discussions on
> different document status for the different documents. e.g. experimental
> versus standards track.
>

---

From: Jacni Qin <[email-masked]>
Date: Mon, 06 Feb 2012 10:26:52 +0800

Hi all,

> in the design team's view, this set of documents are ready to be adopted as working group documents.

No objection to the adoption of the base document, with some comments 
(sorry if they've been discussed ever), please check below.
BTW, another question, I can' t remember the conclusion when the DT was 
chartered, whether the -E and -T were the missions of the DT, or not?

----------------------------------------------------
1. Section 4., ...

    The forwarding function uses the MRT to make forwarding decisions.
    The table consist of the mapping rules.  An entry in the table
    consists of an IPv4 prefix and PSID.  The normal best matching prefix
    algorithm is used.  With a maximum key length of 48 (32 + 16).  E.g.
    with a sharing ratio of 64 (6 bit PSID length) a host route for this
    CE would be a /38 (32 + 6).

I'm confused here. The forwarding is based on routing tables (while IMHO 
the Section 5.3 & 5.4 state it clearer),
the implementations may vary while the basic logic could be:
Each FMR should install one corresponding route in the IPv4 RIB, like,

Rule IPv4 prefix -> "connected", MAP Interface1

For outbound traffic from the private network, when the IPv4 RIB lookup is
performed, it should hit one element with a MAP interface, which can be
used as the pointer to the correct FMR in the MRT, to form the MAP IPv6
address of the destination.

2. Section 5.1.3., more text about what the "offset bits" is for, may 
need to
be added, something like, "The length of offset bits determines the excluded
ports ..."

3. Section 5.2., ...

    The offset of the EA bits field in the IPv6 address is equal to the
    BMR Rule IPv6 prefix length.  The length of the EA bits field (o) is
    given by the BMR Rule EA-bits length.  The sum of the Rule IPv6
    Prefix length and the Rule EA-bits length MUST be less or equal than
    the End-user IPv6 prefix length.

The prefix6-len + EA-bits len must be equal to the End-user IPv6 prefix
length, why there is a "less than"? Any reasonable use case about it?

4. Section 6.,  ...

    In an encapsulation solution, an IPv4 address and port is mapped to
    an IPv6 address.  This is the address of the tunnel end point of the
    receiving MAP CE.  For traffic outside the MAP domain, the IPv6
    tunnel end point address is the IPv6 address of the BR.  The
    interface-id used for all MAP nodes in the domain MUST be
    deterministic.

How to do that, to make the interface-id deterministic? By the
interface-id formula specified?

    ...

    The encoding of the full IPv4 address into the interface identifier,
    both for the source and destination IPv6 addresses have been shown to
    be useful for troubleshooting.

Does this statement apply to translation only, or to both?
----------------------------------------------------------

Cheers,
Jacni