CE Just send packet to BR.
--satoru
On Mon, Mar 3, 2014 at 11:19 PM, Lee, Yiu yiu_...@cable.comcast.com wrote:
Sorry for my ignorance. How MAP-E optimizes states In hub-and-spoke mode
compared to lw4o6?
From: Wojciech Dec wdec.i...@gmail.com
Date: Monday, March 3, 2014 at 1:47 PM
To:
On Mon, Mar 3, 2014 at 11:37 PM, Ian Farrer ianfar...@gmx.com wrote:
[ian] So if you are optimising the amount of state, then you are doing
this at the expense of reduced flexibility in v4/v6 address mapping. In the
interest of balance, it would be fair to point this out.
I couldn't
On Tue, Mar 4, 2014 at 12:13 AM, Qi Sun sunqi.csnet@gmail.com wrote:
Firstly, I still don't understand how MAP-E 'optimize' the state compared
to lw4o6. There are so many modes in MAP, which are you talking about?
Secondly, does the word 'optimize' means 'something is better than the
Satoru Matsushima
Tetsuya Murakami
Tom Taylor
Filename: draft-ietf-softwire-map-08.txt
Pages : 30
Date: 2013-08-12
Abstract:
This document describes a mechanism
On 2013/04/26, at 2:10, cb.list6 cb.li...@gmail.com wrote:
On Thu, Apr 25, 2013 at 8:35 AM, Shishio Tsuchiya shtsu...@cisco.com wrote:
CB
MAP validate onsistency of the source IPv6 address and source port number
for the packet using BMR.
It dicribes section 8.1.
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
On 2013/03/13, at 17:39, Satoru Matsushima satoru.matsush...@gmail.com wrote:
Hi, I couldn't make comment during meeting but,
On 2013
In my view, the MAP-E text, which should be followed by other MAP
related document.
cheers,
--satoru
On Sat, Mar 16, 2013 at 1:57 AM, Poscic, Kristian (Kristian)
kristian.pos...@alcatel-lucent.com wrote:
1) The MAP domain definition should be consolidated across the three
drafts (map-e,
Hi, I couldn't make comment during meeting but,
On 2013/03/12, at 3:28, Ole Troan o...@cisco.com wrote:
- 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)
Does anyone have
Hi Ian,
On 2013/02/15, at 17:29, ian.far...@telekom.de wrote:
Hi Ole,
Assuming that the Unified CPE draft gets adopted by the workgroup, then
there needs to be alignment of the different drafts reflecting this.
The unified CPE draft describes how a CPE interprets the presence (or lack
On 2013/02/15, at 18:34, Xing Li x...@cernet.edu.cn wrote:
Hi, Ian,
The 1:1 mode is a natural characteristic of MAP and removing it from the
draft will cause more confusion. Please also see
https://datatracker.ietf.org/doc/draft-xli-softwire-map-testing/
which shows that a MAP CPE can
On 2013/02/05, at 22:38, Ole Troan o...@cisco.com wrote:
But there has been a firm requirement in the WG that, even for shared
addresses, one of the CE could have the well-known ports.
The WKPs-authorized option has been added to 4rd to satisfy this
requirement.
I don't think this
On 2013/01/25, at 5:08, Tom Taylor tom.taylor.s...@gmail.com wrote:
This caught my eye too. Why repeat the PSID?
Does anyone have the reason of it must not?
cheers,
--satoru
On 24/01/2013 11:27 AM, Ole Troan wrote:
hi,
can we please keep discussion on the list. not via the issue
Hi Yuchi,
On 2012/11/14, at 5:56, Yuchi Chen cheny...@gmail.com wrote:
Hi Satoru,
I think the main issue here is not about naming, but about the original
motivation of MAP. AFAIK MAP draft promotes a stateless provisioning method
using mapping with address and port. Although the
Message-
From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On
Behalf Of Satoru Matsushima
Sent: Tuesday, November 13, 2012 2:07 PM
To: Qiong
Cc: softwires@ietf.org
Subject: Re: [Softwires] MAP-E 1:1 for HA
Qiong,
On 2012/11/13, at 12:57, Qiong bingxu...@gmail.com wrote
Message-
From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com]
Sent: Tuesday, November 13, 2012 5:10 PM
To: Leaf yeh
Cc: Satoru Matsushima; Qiong; softwires@ietf.org
Subject: Re: [Softwires] MAP-E 1:1 for HA
On 2012/11/13, at 17:01, Leaf yeh leaf.y@huawei.com wrote:
I guess
Qiong,
On 2012/11/13, at 12:57, Qiong bingxu...@gmail.com wrote:
+1 agree.
If there is no mapping with addressing and port at all, how can it still be
called MAP anymore ?
It is conventional naming. Even DS-Lite has mapping with address and port.
Please keep discussion constructively.
Hi, I'm in favor of both a) and b).
cheers,
--satoru
On 2012/09/25, at 13:45, Suresh Krishnan suresh.krish...@ericsson.com wrote:
Hi all,
During the softwire WG meeting at IETF84 a series of questions* to
determine the preferred solution in the meeting room indicated that the
sense of the
Hi Yiu,
On 2012/07/26, at 4:08, Lee, Yiu wrote:
Ole,
Where can I get the formal definition of 1:1 mode? My understanding of 1:1
refers to one public IPv4 address per subscriber but you refer very
specific to decoupling IPv4 and IPv6 addresses.
It doesn't 1:1 in MAP and 4rd context,
Support.
--satoru
On Fri, Jul 6, 2012 at 1:33 PM, Suresh Krishnan
suresh.krish...@ericsson.com wrote:
Hi all,
This call is being initiated to determine whether there is WG
consensus towards adoption of draft-mdt-softwire-map-dhcp-option-03 as a
softwire WG draft. Please state whether or not
Remark,
Confusion of current 'draft-ietf-softwire-map-00' version of MAP about 1:1 is
that independence between the ipv6 and ipv4 addressing could be represented as
bellow:
1). ea-len equal to zero within a BMR/FMR for MAP-CE provisioning
2). only DMR provisioning for MAP-CE
So in the 1), it
On 2012/06/27, at 15:38, Peng Wu wrote:
Oh, you don't argue that OSPF covers an use case which is also covered by
RIP. So then why are you arguing that an use case of MAP is eventually same
with the LW46 use case?
I'm clearly saying they have different use cases, but that's not the
point.
@gmail.com wrote:
On Wed, Jun 27, 2012 at 2:57 PM, Satoru Matsushima
satoru.matsush...@gmail.com wrote:
On 2012/06/27, at 15:38, Peng Wu wrote:
Oh, you don't argue that OSPF covers an use case which is also covered by
RIP. So then why are you arguing that an use case of MAP is eventually
same
On 2012/06/27, at 16:43, Peng Wu wrote:
On Wed, Jun 27, 2012 at 2:57 PM, Satoru Matsushima
satoru.matsush...@gmail.com wrote:
On 2012/06/27, at 15:38, Peng Wu wrote:
Oh, you don't argue that OSPF covers an use case which is also covered by
RIP. So then why are you arguing that an use
On 2012/06/27, at 18:20, Qi Sun wrote:
Hi Satoru,
Please see inline.
BTW, my name is Qi :)
Agh! I'm so sorry!
[Qi] What we are discussing is on the essence of MAP where 1:1 mode is
intended to import binding table on BR , and on whether the ietf-map-00 is
qualified as a WG
Qi,
On 2012/06/27, at 19:01, Qi Sun wrote:
[Qi] DHCPv4 over IPv6 is a provisioning method. And it's about the public
IPv4 address allocation, NOT about IPv4 address and IPv6 address mapping. So
there is no state. Please read the draft of DHCPv4 over IPv6 for
clarification.
LW4over6
Hi Maoke-san,
On 2012/06/27, at 20:12, Maoke wrote:
Described text for '1:1 mode' in current version would make some people
confused. We need to make clear for that.
i fully agree with you as zero-lengthed EA-bits is a naturally possible case
of MAP. however, to my understanding, even
On 2012/06/27, at 0:11, Qiong wrote:
Agree with Ian.
MAP is designed and optimized for algorithmatic address mapping, but not for
per-subscriber rule mapping. Actually, the more you would like to solve, more
complicated it will become.
I will certainly not buy MAP for per-subscriber
Hi Maoke,
On 2012/06/27, at 10:48, Maoke wrote:
dear Satoru,
2012/6/26 Satoru Matsushima satoru.matsush...@gmail.com
On 2012/06/27, at 0:11, Qiong wrote:
Agree with Ian.
MAP is designed and optimized for algorithmatic address mapping, but not
for per-subscriber rule mapping
On 2012/06/27, at 12:36, Peng Wu wrote:
Not quite.
I believe that the most motivate to start this work in the wg has destined
MAP to be 'multi-protocol socket v2.0' that's what the former wg chair
wished to. Do you remember that?
i like the philosophy of multi-protocol socket. however, i
Hi Qiong,
On 2012/06/25, at 15:06, Qiong wrote:
Hi Satoru,
Would you please point out in which presentation in the Beijing Interim
meeting illustrated per-subscriber mapping as one characteristic of MAP
solution? I recall which xiaohong presented was a stateful one.
Please find it out
domains which a BR has to manage. I think that will create a huge mapping
table on the BR, which is called 'state' that stateful solutions deal with.
Best Regards!
Qi Sun
From: Satoru Matsushima
Date: 2012-06-25 10:27
To: Lee, Yiu
CC: softwires@ietf.org; Yong Cui
Subject: Re
Hi Maoke-san,
On 2012/06/25, at 12:07, Maoke wrote:
hi Satoru-san, Qiong, and all,
i think the current 1:1 mode text of the draft should be tuned or, it would
be better, to be removed.
technically, i expect MAP as a completely per-session, per-subscriber
stateless solution and
Hi Peng,
On 2012/06/25, at 17:37, Peng Wu wrote:
Please find it out on page 14 from following url:
http://www.ietf.org/proceedings/82/slides/softwire-2.pdf
I think that's not what Alain meant. If you look back and forth a bit,
you can see that:
B1 stands for per-subscriber
Hi Peng,
On 2012/06/25, at 17:50, Peng Wu wrote:
Hmm, I've read 'draft-cui-softwire-b4-translated-ds-lite' as you called
'lightweight 4over6'. LW46 for short, it looks me that MAP just provides
LW46 a provisioning means which would be described in the section 5, or
appendix section
Hi Peng,
On 2012/06/25, at 18:08, Peng Wu wrote:
The discussion in this thread falls in the case of B1. Not the slide
you refered to (slide 14) at all.
Not true. I discuss this thread in the context of B2.
Please read the slides, again.
cheers,
--satoru
Hi Peng,
On 2012/06/25, at 18:34, Peng Wu wrote:
Let's think that a CE provisioned with following BMR comes from MAP DHCPv6
options.
BMR:
o Rule-ipv6-prefix : {exact matched with CE's delegated prefix}
o Rule-ipv4-prefix : x.x.x.x/32
o EA-length : 0
o Port-param option :
that will create a huge mapping
table on the BR, which is called 'state' that stateful solutions deal with.
Best Regards!
Qi Sun
From: Satoru Matsushima
Date: 2012-06-25 10:27
To: Lee, Yiu
CC: softwires@ietf.org; Yong Cui
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map
Hi Qiong,
I'm disagree with your opinion.
1. Recent changes in draft-ietf-softwire-map-00 has been discussed in the DT.
2. MAP just covers so called '1:1 mode' with most granular mapping rule for CEs
provisioning, which is as one of its characteristics.
3. The motivation draft does not restrict
with this document.
Best wishes
On Sun, Jun 24, 2012 at 2:00 PM, Satoru Matsushima
satoru.matsush...@gmail.com wrote:
Hi Qiong,
I'm disagree with your opinion.
1. Recent changes in draft-ietf-softwire-map-00 has been discussed in the DT.
2. MAP just covers so called '1:1 mode' with most
, 2012 at 10:27 AM, Satoru Matsushima
satoru.matsush...@gmail.com wrote:
Hi Yiu,
No, that's a misunderstanding.
Current MAP specify the case for ea-len is 'zero'. It is 'per-subscriber
mapping' in stateless manner, not to introduce 'per-flow NAT binding' or
'per-subscriber state on demand
not to maintain any mapping rule in BR to achieve this?
This could be same operation with any other, configure FMRs into a map tunnel.
Nothing changed.
cheers,
--satoru
Thanks and regards,
Yiu
On 6/24/12 10:27 PM, Satoru Matsushima satoru.matsush...@gmail.com
wrote:
No, that's
Dear Remi,
Thank you for a kind offer. It would be a very positive compromise for us.
However, in the context of making another new stream document, which MAP-bis as
you said, I decline it. Nevertheless, if you abandon 4rd work, I'm very welcome
you as an author of MAP.
Best regards,
--satoru
As a co-author, I'm comfortable with this.
--satoru
On 2012/06/14, at 14:53, mohamed.boucad...@orange.com wrote:
Hi Tom,
Thank for the proposal. I can update the text with your proposed wording if
Dapeng is OK.
Dapeng, are you happy with the text proposed by Tom?
Cheers,
Med
First, thanks Maoke for publishing this document.
It is very helpful to qualify 4rd-u that is a new type IPv4-over-IPv6 tunneling
variant with several semantics changes. I think that it is very exciting
proposal for all IETF participants because they shall be interested into
defining new
So, I choose MAP.
the alternatives we have are perfectly fine:
- Shared IPv4 address over IPv4 transport - NAT444 / CGN
- Shared IPv4 address over IPv6 transport - 464XLAT / DS-lite
- Full IPv4 address over IPv6 transport - DS-lite with Public IPv4 address
Otherwise, I'm tempted to do the
After the meeting, I've figured out that 4rd-u define new type of transport,
since it adds several new semantics in its packet format with V-octet as a
helper of packet format distinguisher. That kind of work is of course out of
scope of Softwire working group. I therefore suggest to the 4rd-u
On 2012/04/02, at 3:02, Satoru Matsushima wrote:
After the meeting, I've figured out that 4rd-u define new type of transport,
since it adds several new semantics in its packet format with V-octet as a
helper of packet format distinguisher. That kind of work is of course out of
scope
On 2012/03/28, at 10:59, Rémi Després wrote:
On the other hand, I couldn't understand the reason of why the CNP is
needed. Since 4rd-u focus on support to communicate between ipv4 hosts, L4
checksum consistency could be agnostic from any kind of 4rd-u nodes.
- Without checksum neutrality,
transparency of original packet so not
only the CNP, but also checksum recalculation are not required.
cheers,
--satoru
On 2012/03/28, at 11:02, Simon Perreault wrote:
On 03/28/12 10:48, Satoru Matsushima wrote:
On the contrary, there is a big difference. The difference is that you are
only
I do agree with Tetsuya-san's comments. On the other hand, I couldn't
understand the reason of why the CNP is needed. Since 4rd-u focus on support to
communicate between ipv4 hosts, L4 checksum consistency could be agnostic from
any kind of 4rd-u nodes. So then I suggest that remove checksum
FYI, section 5 of RFC5082 (http://tools.ietf.org/html/rfc5082#section-5.2)
generalize a technique that TTL is used to help tunnel packets security.
Anyway,
On 2012/03/27, at 14:02, Rémi Després wrote:
Le 2012-03-27 à 13:12, Maoke a écrit :
2012/3/27 Rémi Després despres.r...@laposte.net
As a member of the MAT DT, I am naturally biased in favor of what Xing, Maoke
and Ole said.
I also think that the chair's questions are not adequate. I don't think that
the questions should be which of document the wg choose, make documents to be
unified or not. I think that it should be what
Hi Remi-san, Ole-san,
I still think that configurable suffix would help a case where a MAP CE
cascaded another IPv6 CPE. On the other hand, it is true that second issue,
which Ole-san pointed out that there's difficulty to predict stable prefix for
MAP in that case, which mean MAP wouldn't
On 2012/02/07, at 17:53, Rémi Després wrote:
Le 2012-02-07 à 17:35, Satoru Matsushima a écrit :
On 2012/02/07, at 16:46, Rémi Després wrote:
--snip--
I think that operators who already deploy such dual-stack network is
supposed that they have address mapping table,
I would
On 2012/02/07, at 14:03, Rémi Després wrote:
Le 2012-02-07 à 13:07, Satoru Matsushima a écrit :
Hi Remi-san,
On 2012/02/07, at 11:13, Rémi Després wrote:
Hello Ole, Tetsuya-san, Wojciech,
In a use case described in the 4rd-U draft (sec 5.3), an ISP replaces its
dual-stack routing
On 2012/02/07, at 16:10, Rémi Després wrote:
Le 2012-02-07 à 15:26, Satoru Matsushima a écrit :
On 2012/02/07, at 14:03, Rémi Després wrote:
Le 2012-02-07 à 13:07, Satoru Matsushima a écrit :
Hi Remi-san,
On 2012/02/07, at 11:13, Rémi Després wrote:
Hello Ole, Tetsuya-san
On 2012/02/07, at 16:46, Rémi Després wrote:
--snip--
I think that operators who already deploy such dual-stack network is
supposed that they have address mapping table,
I would rather suppose that ISPs that have added IPv6-prefix delegation,
say /56s, to an existing IPv4 network did
Hi, I'm in favor of the MAP documents suit. I support to adopt these as WG
documents.
cheers,
--satoru
On 2012/01/30, at 20:31, 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
Hi Remi-san,
With this added, I believe that 4rd-U is a real progress over previously
proposed Double translation and Encapsulation.
It can make IMHO a valuable unified standard.
Not enough. The original TTL value in IPv4 header must be carried.
cheers,
--satoru
On 2011/10/17, at 21:36,
not be as same as the virtual link. right?
If so, just double translation is enough for that.
cheers,
--satoru
regards,
maoke
2011/10/17 Satoru Matsushima satoru.matsush...@gmail.com
Hi Remi-san,
With this added, I believe that 4rd-U is a real progress over previously
proposed Double
On 2011/10/17, at 23:46, Maoke wrote:
hi Satoru-san,
2011/10/17 Satoru Matsushima satoru.matsush...@gmail.com
Hi Maoke-san,
On 2011/10/17, at 22:30, Maoke wrote:
hi Satoru-san,
may i understand that, as Remi's proposal is applied for the double
translation case, TTL being
Hi Remi,
It seems far from to be unified _packet_ format. it doesn't support diff-serv
tunneling model, pipe and short-pipe.
cheers,
--satoru
On 2011/10/12, at 18:56, Rémi Després wrote:
Hello all,
The following draft has just been posted:
Leaf, thanks for the summary.
On 2011/10/10, at 20:34, Leaf yeh wrote:
Remi - a1- If the CE has an exclusive or shared IPv4 address:
- 64 8 -- L = 32 ---48-L8
+-++---+---++--+-+---+
| IPv6 prefix |CE index| 0 | V |
On 2011/10/10, at 17:58, Ole Troan wrote:
The 4rd function examines ALL packets that reach the CE.
It processes all those that have V in their destination addresses, and only
those.
This is a big change to the current forwarding behavior of CPE devices,
doable, but quite different from,
.
cheers,
--satoru
Best Regards,
Leaf
-Original Message-
From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com]
Sent: Tuesday, October 11, 2011 4:30 PM
To: Leaf yeh
Cc: Satoru Matsushima; Rémi Després; Ole Troan; Softwires-wg;
fine...@huawei.com
Subject: Re
On 2011/10/09, at 13:31, Maoke wrote:
...
+--+-++
| |source address | destination address|
+--+-++
| CE-CE | N/A|N/A |
Could anyone can share the minutes and an outcome of the interim meeting to the
list?
In particularly, who is the member of design team of address mapping?
cheers,
--satoru
___
Softwires mailing list
Softwires@ietf.org
there is only one sub-
On Mon, Sep 26, 2011 at 6:08 AM, Satoru Matsushima
satoru.matsush...@gmail.com wrote:
Hi auhtors,
I have quick question about your draft.
Section 5 says:
As described above, a stateless 4over6 initiator needs the sub-domain
rule containing subPre6, subPre4
AFTR NAT Bypass: Co-located B4 and NAT Model
http://tools.ietf.org/id/draft-zhou-softwire-b4-nat-02.txt
10:30-10:45 Coffee break
3.Invited talks from operators (90min)
Operator's perspective
10:45-11:15 Satoru Matsushima
An operator's view, address mapping in particular with our
Xiaohong Deng
DS-Lite AFTR NAT Bypass: Co-located B4 and NAT Model
http://tools.ietf.org/id/draft-zhou-softwire-b4-nat-02.txt
10:30-10:45 Coffee break
3.Invited talks from operators (90min)
Operator's perspective
10:45-11:15 Satoru Matsushima
An operator's view, address mapping
Hi auhtors,
I have quick question about your draft.
Section 5 says:
As described above, a stateless 4over6 initiator needs the sub-domain
rule containing subPre6, subPre4 and multiplexing ratio. Since these
parameters are relatively stable, it can be configured in a variety
of
Mohamed, all,
First, thanks for the analysis draft. It sounds good. Let me try to bring my
thought.
An interesting point is here. In the algorithms which define offset to exclude
ports such as 1024, 4096 whatever, the efficiency of port utilization is
decreased, which algorithm is 4rd, and
Remi-san,
On 2011/09/14, at 15:20, Rémi Després wrote:
...
Let's take the example of sec. 6 (A), namely:
+++-+
| Domain IPv4 prefix | Domain IPv6 prefix | AFTR IPv6 subnet (e.g.) |
Med,
On 2011/09/14, at 14:40, mohamed.boucad...@orange-ftgroup.com wrote:
Hi Rémi,
I didn't get my answer yet. I'm looking for the explanation about the
behaviour of an 6/4 interconnection node receiving IPv4 packets destined to
CPEs assigned with port sets of different sizes. What is
2011/8/19 Rémi Després despres.r...@laposte.net:
I think so.
I know that some, although expressing nothing against the idea, would prefer
to wait and see.
I haven't heard so.
But others believe that, concerning the best way to structure drafts, the
earlier is the better.
IMHO, document
On 2011/08/19, at 5:14, Jan Zorz @ go6.si wrote:
On 8/18/11 3:59 PM, GangChen wrote:
A+P is the same case if I understand correctly. NAT44 is one of three
fundamental functions in A+P architecture. Otherwise, it can’t connect
to legacy end-hosts.
Usually yes, but not necessary. PAT could
Dear Nejc,
On 2011/08/17, at 22:58, Nejc Škoberne wrote:
Dear Gang,
as far as I can understand your draft, you make NAPT44 in the CE obligatory.
[Gang] Yes. This is to avoid the problem where there are applications
that attempt
to bind to specific ports that are not part of the allowed
Hi Qiong,
in fact, 4rd doesn't require specific format to ipv6 address.
what do you find in 4rd?
--satoru sent from my iPad
On 2011/08/09, at 15:48, Qiong bingxu...@gmail.com wrote:
Hi Yiu, Jacni,
On Tue, Aug 9, 2011 at 9:25 AM, Lee, Yiu yiu_...@cable.comcast.com wrote:
So the only
On 2011/08/02, at 12:10, Jacni Qin wrote:
hi Jan,
On 8/1/2011 10:36 PM, Jan Zorz @ go6.si wrote:
On 8/1/11 1:07 PM, Satoru Matsushima wrote:
So my question is that how dynamic is dynamic, and how static is
static. The analogy of dynamic routing is that dynamic for updating
routing
On 2011/08/02, at 5:14, Jan Zorz @ go6.si wrote:
On 8/1/11 5:04 PM, Qiong wrote:
So, this is a problem about how to define appropriate port set for our
customers, or to define maximum concurrent subscribers for a given IPv4
address pool. Otherwise, there would either be a waste of resource,
Hi Yiu,
One clarification.
On 2011/08/02, at 2:29, Lee, Yiu wrote:
Actually, Orange Lab did some tests on A+P. They published the results in
v6ops:
http://tools.ietf.org/html/draft-deng-v6ops-aplusp-experiment-results-01
In their tests, bittorrent seems use most ports (200). Other
it. Then I think that we should take
'draft-cui-softwire-b4-translated-ds-lite' as a solution for b).
cheers,
--satoru
Thanks
Best wishes
Qiong Sun
On Sat, Jul 30, 2011 at 9:57 PM, Satoru Matsushima
satoru.matsush...@gmail.com wrote:
One clarification.
On 2011/07/29, at 10:18
On 2011/08/01, at 18:26, Jan Zorz @ go6.si wrote:
Well, A+P got enormous amounts of criticism because there was no dynamic
allocations of additional ports.
Now we don't need that anymore, just because stateless solution can't handle
it by design?
I love stateless a+p flavors, but imho
On 2011/08/02, at 5:21, Jan Zorz @ go6.si wrote:
On 8/1/11 5:50 PM, Ole Troan wrote:
Jan Zorz @ go6.si wrote, on 08/01/2011 10:36 AM:
Well, is short words, whatever number of ports you assign in
port-set/range, end user can exhaust them.
The fact that most ISPs have been successfully
One clarification.
On 2011/07/29, at 10:18, GangChen wrote:
Before making such comparison (of course it should be as fair as possible),
I think we need to state what solution space we are targeting and what
category mode we should take care.
If I understand correctly, I would paraphrase as
Cameron,
On 2011/07/29, at 10:27, Cameron Byrne wrote:
I am skeptical about stateless operation scaling. I don't even have 2000
ports per user (growth to 2015 ...), and I don't want to get into a position
where I have to tactically move ipv4 addresses around to meet demand.
That's a
Hello Qiong,
On 2011/07/28, at 2:28, Qiong wrote:
Dear all,
Following the recent discussion on stateless 4v6 solutions, I'm still
wondering how to define or plan a reasonable stateless 4v6 domain in reality.
My main concern is how to distinguish between multiple different domains with
Hi Qiong,
On 2011/07/28, at 4:31, Qiong wrote:
Hi, Satoru,
Thanks a lot for your suggestion and I understand it can work. But in my
understanding, it still lies some differences with the so-called totally
stateless solution.
I don't mean that 'totally stateless solution' isn't a part
Dave, thank you to share your slides.
--satoru
On 2011/07/28, at 15:45, Dave Thaler wrote:
Attaching here since they don't seem to be posted yet.
-Dave
-Original Message-
From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On
Behalf Of Satoru Matsushima
Sent
Hi Jari,
Thank you for your comments. Please see inline:
On 2011/07/23, at 10:36, Jari Arkko wrote:
I have reviewed this draft in preparation for discussions in the upcoming
meeting.
Thanks for writing this. In general, I agree with many of the points raised
in the document. I do have
I agree with Remi and Hui. The motivation draft has been understood enough and
has consented around people.
But I'm very curious what 'Chairs Discussion' is in the agenda to have 10
minutes. What the chairs want to discuss about the motivation? Isn't it
possible in the list?
cheers,
--satoru
Jacni,
On 2011/07/20, at 12:07, Jacni Qin wrote:
hi Authors, all,
I skimed the draft and got a question on the Domain IPv4 Prefix involved in
the algorithm,
Since currently the IPv4 blocks used for accessing residential users are
probably fragmented (or not that continuous), I guess
Dear Alain,
I'm very happy to have discussion, not only in Quebec meeting, but also on the
list.
Actually, we had two month from we submitted the initial version. While that
time, we received many valuable comments and discussions from people. Most
significant thing we did is that we have
On 2011/07/08, at 2:16, Mark Townsley wrote:
Sure, based on your review of the document that's fine. But, not the thread
from a WG chair perspective as stated above. That's ridiculous.
I hope that the chair take adoption to be a WG document.
Please discriminate your chair role from your
Dear Softwires Working Group chairs,
I support that an request from Mohamed to make WG adoption as appropriate
charter item.
I'm looking forward you to take your kind adoption procedure for the request.
Sincerely yours,
--
Satoru Matsushima
On 2011/06/10, at 20:31, mohamed.boucad...@orange
Hi,
On 2011/05/27, at 3:19, Behcet Sarikaya wrote:
You mean after merging with draft-chen-softwire-4v6-motivation-00.txt?
then +1 from me.
The authors of both drafts are now co-working to integrate unified version so
we'll submit it soon. We would like to invite your comments. Any feedback
OLNC/NAD/TIP
Cc : Satoru Matsushima; Yiu Lee; Olaf Bonness; Isabel Borges; Softwires-wg
Objet : Re: [Softwires] Motivation draft for stateless v4 over v6 solution
Le 9 mai 2011 à 15:37, mohamed.boucad...@orange-ftgroup.com
mohamed.boucad...@orange-ftgroup.com a écrit :
...
Med
Dear colleague,
We've uploaded an I-D to express our motivation of stateless IPv4 over IPv6 as
an IPv6 transition solution. Since the outcome of recharter session in last
softwires wg meeting, ADs required the motivation draft to standardize
stateless v4 over v6 solution at IETF.
We, authors
I'm very confused to understand what DS-Lite is.
On 2011/04/21, at 10:22, Yong Cui wrote:
Change DS-Lite with no NAT or NAT on the B4 element to No NAT on AFTR
However, draft-ietf-softwire-dual-stack-lite-07 clearly express AFTR is
carrier grade NAT44,
and B4(CPE) should not operate a NAT
Hello,
I have some comments for the recharter text.
4. Developments for stateless legacy IPv4 carried over IPv6
What does legacy mean?
I think that no adjective needs to what IPv4 is.
- develop a solution motivation document to be published as an
RFC
- develop a protocol
1 - 100 of 108 matches
Mail list logo
