Subject: [Softwires] MAP tracker issues

From: Ole Troan <[email-masked]>
Date: Mon, 11 Mar 2013 13:28:54 -0500

hi,

as agreed in the meeting here is the summary of the discussion of the MAP open issues.
the plan is to leave these open for discussion for a week (until next Monday),
then issue revision -05, that we will ask to be last called in the WG.

#18     Title and file name of the MAP-E draft need to be updated       
          No-one in the room objected to keeping name as is.
          Close ticket.

#19     IPv4 address superfluous in MAP-E Interface IDs map-e                   
          No one in the room objected to keeping interface-id as is in revision 04.
          Close ticket.

#21     Fragmentation must not be handled according to RFC 2473 map-e           
          It is an issue, but it is a generic problem that should be fixed in a RFC2473bis.
          Have descriptive text in the MAP document describing the issue and referencing RFC4459.

          Current proposed text:
          "Multiple BRs using the same anycast source address could send
   fragmented packets to the same CE at the same time.  If the
   fragmented packets from different BRs happen to use the same fragment
   ID, incorrect reassembly might occur.  See [RFC4459] for an analysis
   of the problem.  Section 3.4 suggests solving the problem by 
   fragmenting the inner packet."

          Close ticket with above text.
          Chairs to consider RFC2473bis
         
#25     Maintain or remove MAP1:1 Mode?
          Remove section 7.4 (Address Independence). Rename 1:1 example.

- Offset 4 versus 6.
  Discussion on value of wasting 3000 port versus simplicity of nibble alignment.
  No objection to moving default offset to 6 (from 4 in revision 04)

- Updated text for appendix B
  Tom Taylor to propose updates to appendix B (GMA appendix).

cheers,
Ole

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 13 Mar 2013 17:39:25 +0900

Hi, I couldn't make comment during meeting but,

>  No objection to moving default offset to 6 (from 4 in revision 04)

Does anyone have a evaluated result of NAT performance difference in the number of derived port range? 
ie. 63 port ranges (6 bits offset) vs 15 port ranges (4 bit offset) on a CPE.

It would be better to see the result which show it could be negligible with the updated text.

cheers,
--satoru

---

From: Satoru Matsushima <[email-masked]>
Date: Sun, 17 Mar 2013 00:34:27 +0900

As each implementation has its own, but I heard at least two implementors confirm that it is negligible difference between 15 to 63, done.

cheers,
--satoru

---

From: Xing Li <[email-masked]>
Date: Sun, 17 Mar 2013 02:19:24 +0800

> As each implementation has its own, but I heard at least two implementors confirm that it is negligible difference between 15 to 63, done.
there is no performance impact for cernet's map cpe. xing
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>
>
>

---

From: Shishio Tsuchiya <[email-masked]>
Date: Sun, 17 Mar 2013 05:12:55 -0400

I know 3 Geeks who lived in IPv4 15 port and IPv6 internet environment.
They reported it was comfortable for home network.

And JANOG tested 15port of MAP-E.
http://tools.ietf.org/html/draft-janog-softwire-report-01#section-4.9
MAP-E provides IPv6 to CPE,so CPE can use DNS resolver proxy.

There is no performance impact,if they supported DNS proxy.

Regards,
-Shishio

(2013/03/16 14:19), Xing Li wrote:
>>> Does anyone have a evaluated result of NAT performance difference in the number of derived port range? ie. 63 port ranges (6 bits offset) vs 15 port ranges (4 bit offset) on a CPE.
>>>

---

From: Ted Lemon <[email-masked]>
Date: Sun, 17 Mar 2013 11:52:33 +0000

> They reported it was comfortable for home network.

Wow.   Do you have any idea what traffic remained on IPv6 while they were doing this?

---

From: Tom Taylor <[email-masked]>
Date: Sun, 17 Mar 2013 20:03:41 -0400

I would think the number of blocks through which the ports are scattered 
has very little relevance to the user experience. Surely the key factor 
is the sharing ratio?

Tom Taylor

> There is no performance impact,if they supported DNS proxy.
...

---

From: Shishio Tsuchiya <[email-masked]>
Date: Mon, 18 Mar 2013 11:31:26 +0900

> Wow.   Do you have any idea what traffic remained on IPv6 while they were doing this?

I'm not sure in detail,but they might be enough to live if they can access to facebook,google,ietf and JANOG.:-)
I think,there are some reasons to comfortable.
-Hyper Giants and technical site are already enabled IPv6.
-All of DNS query send to IPv6 DNS server.
-The CPE implementation was completely made to provide A+P function.(not reuse existing NAT implementation)
-Web communication improvement(SPDY or Websocket?)

Regards,
-Shishio

---

From: Shishio Tsuchiya <[email-masked]>
Date: Mon, 18 Mar 2013 12:14:48 +0900

Tom
I misunderstood original question.
- Offset 4 versus 6.
  Discussion on value of wasting 3000 port versus simplicity of nibble alignment.
  No objection to moving default offset to 6 (from 4 in revision 04)

I think,this is NOT impact for user experience and implementations.

Regards,
-Shishio

(2013/03/18 9:03), Tom Taylor wrote:
> I would think the number of blocks through which the ports are scattered has very little relevance to the user experience. Surely the key factor is the sharing ratio?
> 
> Tom Taylor
> 
> .

---

From: Ole Troan <[email-masked]>
Date: Mon, 18 Mar 2013 13:13:44 +0100

all,

I have posted a new revision which implements all the agreed resolutions in
Orlando. including renaming the example sections referring to 1:1.

new draft and diffs are available here:

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-softwire-map-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-05

I have also closed the tickets as agreed in Orlando. please do not reopen them.

this draft should now be ready for a WGLC.

Best regards,
Ole