...@ietf.org [mailto:softwires-boun...@ietf.org] On
Behalf Of Simon Perreault
Sent: Tuesday, April 03, 2012 8:16 PM
To: softwires@ietf.org
Subject: Re: [Softwires] Path to move forward with 4rd… 4rd-U as transparent
as MAP-E
On 2012-04-03 05:40, Ole Trøan wrote:
1) MAP-E supports independence
Le 2012-04-03 à 14:43, guoliang han a écrit :
Hi, Remi:
I don't think my case illustrates MAP-T needs to remain experimental, my
comments are below:
2012/4/3 Rémi Després despres.r...@laposte.net
Hi, Guoliang,
Interesting enough, the example you give illustrates that MAP-T
2012/4/3, Wojciech Dec wdec.i...@gmail.com:
On 2 April 2012 19:10, Rémi Després despres.r...@laposte.net wrote:
Woj Well, in terms of facts we have
1. 4rd-U does not supporting single translation mode,
Not claimed to.
It's good to get clarity now that previous 4rd-U claims of
2012-04-03 18:32, Marc Blanchet :
I don't see a way out of this thread.
my suggestion:
- published both as experimental
- let the market decide
- come back later to move one or the other standard track.
+1
RD
Above all, I think having a stable specification (i.e. RFC) that
Here's the situation. There was no clear consensus in the WG meeting in Paris.
But the IETF conducts its business on the mailing list, so - as we always do -
the chairs asked for feedback on the two questions asked in Paris. We'll use
the responses to assess if there is consensus for the
On 4/3/12 3:53 AM, Satoru Matsushima wrote:
FYI, choosing MAP doesn't mean that committing to a 'single'. But
choosing 4rd-u means that committing to a 'single'.
There're just transport variants, which are encapsulation,
translation and new one we've never seen before. Proponents of the
new one
Le 2012-04-03 à 03:53, Satoru Matsushima a écrit :
FYI, choosing MAP doesn't mean that committing to a 'single'. But choosing
4rd-u means that committing to a 'single'.
There're just transport variants, which are encapsulation, translation and
new one we've never seen before. Proponents
If you would have a detailed scenario where ANY transparency difference could
be noticeable e2e between a MAP-E tunnel and a 4rd-U tunnel, this sentence
would be fair.
However, you haven't shown such a scenario, and AFAIK you can't have one
because it doesn't exist.
The above assertion,
Le 2012-04-03 à 11:40, Ole Trøan a écrit :
If you would have a detailed scenario where ANY transparency difference
could be noticeable e2e between a MAP-E tunnel and a 4rd-U tunnel, this
sentence would be fair.
However, you haven't shown such a scenario, and AFAIK you can't have one
Hi, Remi:
Pls read my comments below.
2012/4/3 Rémi Després despres.r...@laposte.net
2012-04-03 14:43, guoliang han :
Hi, Remi:
I don't think my case illustrates MAP-T needs to remain experimental, my
comments are below:
2012/4/3 Rémi Després despres.r...@laposte.net
Hi, Guoliang,
Le 2012-04-03 à 15:41, Guoliang a écrit :
Hi, Remi:
Pls read my comments below.
2012/4/3 Rémi Després despres.r...@laposte.net
Le 2012-04-03 à 14:43, guoliang han a écrit :
Hi, Remi:
I don't think my case illustrates MAP-T needs to remain experimental, my
comments are below:
Dear Softwires WG chairs.
For how long will you leave this useless cockfight go on instead of
steering the working group into a direction, that may enable us to
decide on something and chose the direction?
We are running in circles here and just amplificating the noise, coming
from certain
Hi Remi,
Do we need them to be sure in spite of we already have existing mature
transport variants?
MAP-E+T isn't as mature as repeatedly claimed.
MAP-T may be more imprecise than MAP-E in this respect, but both have known
bugs to be fixed (at least packet IDs of shared-addres CEs of
I don't see a way out of this thread.
my suggestion:
- published both as experimental
- let the market decide
- come back later to move one or the other standard track.
Above all, I think having a stable specification (i.e. RFC) that implementers
can code against and providers to require is
The irony is that this is an apples and oranges comparison, and throwing
away ripe apples into some box with raw oranges looks rather unfair.
Some of the of the indicators are:
- MAP is not only the result of a consensus of a broad WG design team, but
also that of numerous authors of the merged
well, i cannot help but send out this late Apr-1 joke: let's see what is
the problem publishing the two document plus an informational doc analysing
what problems 4rd-u introduces to architecture and real operation, with
them all stable and having an RFC number for each? if this is fine, we all
Fully agree with Maoke!
This is not just the issue of publishing two documents...To accormodate
with 4rd-U, many existing RFCs should be updated, like RFC
4291,RFC6052,etc. There is no evidence to show that we need to do that
because 4rd-U havn't been shown that it is workable in today's
2012/4/2 Rémi Després remi.desp...@free.fr
Frankly, I don't understand the new objection: concern if 4rd-u
possibly introduces... is IMHO an incitation to FUD, but not a technically
justified issue.
If you can detail what you mean, with a point an experiment might reveal,
dialogue will
2012/4/2 Rémi Després despres.r...@laposte.net
it is flawed in both architecture and technical aspects,
Which ones?
please refer to discussion mails and also my real-time comments on 4rd-u
presentation in the jabber room as a brief summary focusing on major
points. - maoke
Le 2012-04-02 à 11:16, Maoke a écrit :
2012/4/2 Rémi Després despres.r...@laposte.net
it is flawed in both architecture and technical aspects,
Which ones?
please refer to discussion mails
I carefully read all emails addressed to me, plus most others, but don't
understand
Le 2012-04-01 à 20:11, Satoru Matsushima a écrit :
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
2012-04-02 11:45, Maoke:
...
i am still in review on the version -06, but i have found something not
qualified (inconsistent semantics).
Asserting there are flaws implies ability to describe them.
What you have already found will be looked at fairly when described. (Just
saying inconsistent
2012/4/2 Rémi Després despres.r...@laposte.net
but it is less informative.
Less informative than what?
well i found that, through the ietf agenda page:
http://www.ietf.org/jabber/logs/softwire/2012-03-30.html, FYI.
less informative than my email discussions.
if the unified header
If this is to say that until a BOF is started, you will keep your
objection(s) unknown, I continue to take it as a lack of identified
objections.
the objections I'm aware of are:
- people are uncomfortable with only a double translation solution
* injection of IPv4 routes into IPv6
*
2012/4/2 Rémi Després despres.r...@laposte.net
2012-04-02 11:45, Maoke:
...
i am still in review on the version -06, but i have found something not
qualified (inconsistent semantics).
Asserting there are flaws implies ability to describe them.
What you have already found will be looked
On 4/2/12 12:33 PM, Ole Trøan wrote:
the status quo; with no path forward just means that we'll
effectively kill A+P. I would certainly not recommend my product
managers to implement either of this given the risk. is there
consensus to abandon these efforts (which is basically what we do by
On Apr 2, 2012, at 12:44 , Jan Zorz @ go6.si wrote:
On 4/2/12 12:33 PM, Ole Trøan wrote:
the status quo; with no path forward just means that we'll
effectively kill A+P. I would certainly not recommend my product
managers to implement either of this given the risk. is there
consensus to
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
于 2012/4/2 19:13, Ole Trøan 写道:
On Apr 2, 2012, at 12:44 , Jan Zorz @ go6.si wrote:
On 4/2/12 12:33 PM, Ole Trøan wrote:
the status quo; with no path forward just means that we'll
effectively kill A+P. I would certainly not recommend my product
managers to implement either of this given the
Remi,
(please don't respond to these, FYI only. I'm on Easter holiday.)
Asking that a list of objections shouldn't be answered is to me very unusual!
it was to remind you of the problems with 4rd-U. we have been many rounds on
these exact arguments, and I don't see the point of rehashing
Le 2012-04-02 à 16:05, Ole Trøan a écrit :
Remi,
(please don't respond to these, FYI only. I'm on Easter holiday.)
Asking that a list of objections shouldn't be answered is to me very unusual!
it was to remind you of the problems with 4rd-U.
we have been many rounds on these exact
On Apr 2, 2012 8:17 AM, Wojciech Dec wdec.i...@gmail.com wrote:
On 2 April 2012 15:46, Rémi Després despres.r...@laposte.net wrote:
Le 2012-04-02 à 12:33, Ole Trøan a écrit :
If this is to say that until a BOF is started, you will keep your
objection(s) unknown, I continue to take it as
Cameron,
- less IPv4 exit mechanisms to implement and choose among. that must be
good, no?
(currently there are at least 4 mechanisms proposed in the A+P HS and
mesh space)
- large stateful boxes in the SP network; we know how to build them,
and we can charge more for them. that's
Remi,
(this reminds me of cockfighting; somewhat entertaining for the spectators
(if that's your kind of thing), one is declared a winner, but both
combatants die...
You may fear that MAP T+E would be about to die (your judgement) but, in
particular in view of the quotation above, I
On 2 April 2012 19:10, Rémi Després despres.r...@laposte.net wrote:
Woj Well, in terms of facts we have
1. 4rd-U does not supporting single translation mode,
Not claimed to.
It's good to get clarity now that previous 4rd-U claims of supporting
services such as web-caching,
+1.
4rd-u is tweaking IPv6 header such as fragment header, hop limit, V-octet, etc
to create a unified transport instead of the encapsulation (MAP-E) and the
translation (MAP-T). MAP-E and MAP-T do not intend to create a new transport.
In fact, MAP-E utilizes rfc2473 and MAP-T utilizes
2012/4/3 Satoru Matsushima satoru.matsush...@gmail.com:
FYI, choosing MAP doesn't mean that committing to a 'single'. But choosing
4rd-u means that committing to a 'single'.
There're just transport variants, which are encapsulation, translation and
new one we've never seen before.
+1.
As a follower of MAP team, I participated much in developing and deploying
double-translation in CERNET. As far as I am concerned, in the translation
scenario,
4rd-U only solved some corner cases but missed some other cases
simultaneously.
As an example, I suppose one fragmentation case as
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 of
hi all,
i listented to the softwire wg live on March 30 online and recorded my
comments in the jabber room. as the person who was mentioned by the
presenter not less than twice, i have to point out that it is unfair that
the presenter mentioned me with only acknowledgment to my effort but my
On 3/26/12 8:54 PM, Satoru Matsushima satoru.matsush...@gmail.com
wrote:
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
Dear WG Co-Chairs,
I looked at your arguments in this email here and Softwaire WG agenda you
proposed on Wed and Fri, I am kind of confusing, hope you can clarify:
There are several drafts discussed in Wed agenda which basically solved
same problem as we discussed in Friday and they are all
Maoke,
I like your analog of horse, donkey, and donkorse! and fully agree with you.
People know what kind of situation horse and donkey can help to solve the
problem. People do not want unknown donkorse because it creates more
problem rather than solving specific problem.
Kevin Yin
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
Le 2012-03-25 à 05:34, Maoke a écrit :
dear Remi,
2012/3/24 Rémi Després despres.r...@laposte.net
Le 2012-03-22 à 15:40, Maoke a écrit :
dear Alain, Yong, Ralph and all,
in program, the effort of the MAP team should be respected. The formation of
the MAP team was also the consensus
2012/3/25 Rémi Després despres.r...@laposte.net
some issues remaining not yet reaching collective undertanding is not a
reason of making things over. the collective understanding has been reached
for the major part of the
1) MAP address format and the corresponding algorithms
2)
Maoke,
(Retransmission after deleting unnecessary old text. Message was too big for
the mailing list)
2012-03-25 14:08, Maoke :
2012/3/25 Rémi Després despres.r...@laposte.net
...
you may argue that MAP is much more fuzzy. but as i said, nobody knows
exactly what the 4rd-u tunnel is.
: 1
Date: Sat, 24 Mar 2012 17:29:43 +0100
From: Jan Zorz @ go6.si j...@go6.si
To: softwires@ietf.org
Subject: Re: [Softwires] Path to move forward with 4rd?
Message-ID: 4f6df677.8080...@go6.si
Content-Type: text/plain; charset=windows-1252; format=flowed
On 3/23/12 4:04 AM, Guanghui Yu wrote:
Hi
dear Remi,
2012/3/24 Rémi Després despres.r...@laposte.net
Le 2012-03-22 à 15:40, Maoke a écrit :
dear Alain, Yong, Ralph and all,
in program, the effort of the MAP team should be respected. The formation
of the MAP team was also the consensus of our meeting in beijing and we
have seen
4rd-U is in the very early design stage, there is no running code. In addition,
it tries to modify the IPv6 address architecture. We need to see the
experimental data before making any decision.
--
Zhang Huanjie
E-mail/msn: ja...@ustc.edu.cn
___
Is there experimental data for MAP running on production networks?
Certainly that is an important point to consider.
On 3/22/12 11:06 PM, Zhang Huanjie ja...@ustc.edu.cn wrote:
4rd-U is in the very early design stage, there is no running code. In
addition, it tries to modify the IPv6 address
Alain, et al,
we have been at an impasse, so thank you very much for proposing a path forward.
After a number of discussions with my co-chair, our AD and various authors,
here is how we would like to move forward wrt 4rd.
1) There is an observation that all the solutions on the table E, T
Hi Penno,
MAP-T was derived from dIVI and dIVI-PD, which has been running at CERNET2
for two years and have been tested at China Telcom both in Beijing and
Hunan last year. In addition, the dIVI-PD was demonstrated successfully in
Softwire Interim Meeting in Beijing last September. BTW, the
...@ietf.org] De la part de Alain Durand
Envoyé : mardi 20 mars 2012 00:39
À : Softwires WG
Cc : Yong Cui; Ralph Droms
Objet : [Softwires] Path to move forward with 4rd.
Dear wg,
After a number of discussions with my co-chair, our AD and
various authors, here is how we would like to move forward wrt 4rd
To: Zhang Huanjie ja...@ustc.edu.cn, Softwires WG softwires@ietf.org
Cc:
Subject: Re: [Softwires] Path to move forward with 4rd
Is there experimental data for MAP running on production networks?
Certainly that is an important point to consider.
On 3/22/12 11:06 PM, Zhang Huanjie ja
Le 2012-03-22 à 13:26, Guanghui Yu a écrit :
Hi all
This mail raises a very important issue. MAP-T and MAP-E are not
competing technologies. They have different user scenarios.
I read 4rd-u draft and found it is flawed.
Please explain what, in your understanding, would be flawed.
to substitute dIVI and dIVI-PD by MAP-T or run them in
parallel?
From: Congxiao Bao cx.cer...@gmail.com
Date: Fri, 23 Mar 2012 18:04:47 +0800
To: Cisco Employee repe...@cisco.com
Cc: Zhang Huanjie ja...@ustc.edu.cn, Softwires WG softwires@ietf.org
Subject: Re: [Softwires] Path to move forward
From: Wojciech Dec wdec.i...@gmail.com
Date: Fri, 23 Mar 2012 13:26:48 +0100
To: Cisco Employee repe...@cisco.com
Cc: Congxiao Bao cx.cer...@gmail.com, Softwires WG softwires@ietf.org
Subject: Re: [Softwires] Path to move forward with 4rd
Hi,
On 23 March 2012 13:10, Reinaldo Penno repe
2012 18:04:47 +0800
To: Cisco Employee repe...@cisco.com
Cc: Zhang Huanjie ja...@ustc.edu.cn, Softwires WG softwires@ietf.org
Subject: Re: [Softwires] Path to move forward with 4rd
Hi Penno,
MAP-T was derived from dIVI and dIVI-PD, which has been running at
CERNET2 for two years and have
-Message d'origine-
De : softwires-boun...@ietf.org
[mailto:softwires-boun...@ietf.org] De la part de Alain Durand
Envoyé : mardi 20 mars 2012 00:39
À : Softwires WG
Cc : Yong Cui; Ralph Droms
Objet : [Softwires] Path to move forward with 4rd.
Dear wg,
After a number
Le 2012-03-22 à 15:40, Maoke a écrit :
dear Alain, Yong, Ralph and all,
in program, the effort of the MAP team should be respected. The formation of
the MAP team was also the consensus of our meeting in beijing and we have
seen the the team is working with clear progress. I don't think
Subject: Re: [Softwires] Path to move forward with 4rd
Well, MAP-T and divi-pd in non-address-sharing mode (ie 1:1) should be
totally compatible. However, given that the on-the-wire encoding of the
PSID is different in the address sharing mode, interoperability in that mode
won't be there.
Cheers
Hi all
This mail raises a very important issue. MAP-T and MAP-E are not
competing technologies. They have different user scenarios. I read 4rd-u
draft and found it is flawed. I will not support the adoption of 4rd-u,
since there is no running code and there is no experimental evaluation. In
Hello Chairs, all
In essence, while at a very high level all solutions appear to solve a
common problem, just like all ducks look the same, some solve extra
problems that are of critical importance to some operators, this forms the
basis for the different approaches, and what led to the MAP draft
On 3/20/12 12:38 AM, Alain Durand wrote:
Q1: Without pre-supposing which one will be selected, do you agree to
publish 1 of the 3 proposals on the Standard Track and publish the
other(s) as Informational if still asked to?
If the answer is NO, then the process stops and we will publish
...@cernet.edu.cn
To: Alain Durand adur...@juniper.net
Cc: Softwires WG softwires@ietf.org, Yong Cui cuiy...@tsinghua.edu.cn,
Ralph Droms rdr...@cisco.com
Sent: Wednesday, 21 March, 2012 9:39:07 PM
Subject: Re: [Softwires] Path to move forward with 4rd…
Hi, Alain, Yong and Ralph,
The newly posted agenda
-
From: Alain Durand adur...@juniper.net
Date: Mon, 19 Mar 2012 16:38:42 -0700
To: Softwires WG softwires@ietf.org
Cc: Yong Cui cuiy...@tsinghua.edu.cn, Ralph Droms rdr...@cisco.com
Subject: [Softwires] Path to move forward with 4rd
Dear wg,
After a number of discussions with my co-chair, our AD
Hi, Alain, Yong and Ralph,
The newly posted agenda does not match the consensus as you mentioned on
6 Oct 2011, that “multiple address and port mapping technologies could
and should converge” and you formally announced “the creation of the MAP
(Mapping of Addresses and Ports) design team”, a
Dear wg,
After a number of discussions with my co-chair, our AD and various authors,
here is how we would like to move forward wrt 4rd.
1) There is an observation that all the solutions on the table E, T U
actually solve the stateless problem we started with.
There are differences, but
70 matches
Mail list logo
