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
Dear Ole and yuchi chen,
Thank you for your correction. I have understood it.
Best regard!
sunjingwen
From: Yuchi Chen
Date: 2012-04-01 19:38
To: Ole Trøan
CC: softwires WG; sunjingwen
Subject: Re: Re: [Softwires] [softwire]Basic Requirements for Customer Edge
Routers
Dear Ole,
Thanks
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
Hi, Congxiao,
During the Softwire meeting, you came to the mike to assert that the 4rd-U
specification was known to have flaws.
Yet, you do know that the 4rd-U specification has been reviewed by competent
contributors of widely varied origin, with no identified flaw left in the
draft.
Since
于 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
23 matches
Mail list logo
