Le 19 août 2011 à 03:08, Satoru Matsushima a écrit :
Hello Remi-san,
I've found this mail now.
On 2011/07/16, at 22:55, Rémi Després wrote:
Hi all,
1.
Being active in the IETF community has been overall enjoyable but, for
various personal reasons including financial,
I will no
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
Le 19 août 2011 à 10:15, Satoru Matsushima a écrit :
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.
If I misinterpreted what I saw, that's even better.
But
Hi Satoru-san,
Please see my comments inline.
On 2011/08/18, at 18:08, Satoru Matsushima wrote:
Hello Remi-san,
I've found this mail now.
On 2011/07/16, at 22:55, Rémi Després wrote:
Hi all,
1.
Being active in the IETF community has been overall enjoyable but, for
various
Le 18 août 2011 à 09:18, Washam Fan a écrit :
It seems to me, when delegating CE ipv6 prefix, a longest match might
be used.
OK, but, again, if a realistic use case is available where longest match is
indeed REQUIRED, there is no problem to impose longest match.
What is missing so far is
Hi folks,
We, softwire wg chairs, in agreement with our ADs, are announcing
an interim meeting in Beijing on September 26 27. The date has
been chosen adjacent to the BBF meeting in Shangai to minimize
travel and visa issues.
The interim meeting will focus on 'stateless' solutions in general
On 2011-08-18 22:03, GangChen wrote:
2011/8/18, Simon Perreault simon.perrea...@viagenie.ca:
On 2011-08-18 09:59, GangChen wrote:
NAT44 is one of three
fundamental functions in A+P architecture. Otherwise, it can’t connect
to legacy end-hosts.
What if in my deployment scenario there are no
2011/8/19 Rémi Després despres.r...@laposte.net:
Le 18 août 2011 à 09:18, Washam Fan a écrit :
It seems to me, when delegating CE ipv6 prefix, a longest match might
be used.
OK, but, again, if a realistic use case is available where longest match is
indeed REQUIRED, there is no problem to
Yong,
Why is dIVI not included In the discussion ?
Could you please clarify?
Cheers,
Rajiv
Sent from Phone
On Aug 19, 2011, at 8:10 AM, Yong Cui cuiy...@tsinghua.edu.cn wrote:
Hi folks,
We, softwire wg chairs, in agreement with our ADs, are announcing
an interim meeting in Beijing
Particularly when targeting the consumer appliance space, fewer documents are
better than many. Softwires should be working to converge on a single concise
and clear RFC for the stateless ds-lite mode of operation.
- Mark
On Aug 18, 2011, at 9:08 PM, Satoru Matsushima wrote:
Hello
Rajiv,
I would be very happy to see the progress of dIVI.
However, according to our current Softwire charter and Milestones,
dIVI is not the most urgent thing to do in Softwire.
Yong
-Original Message-
From: Rajiv Asati (rajiva) raj...@cisco.com
Date: Fri, 19 Aug 2011 08:16:05 -0400
To:
于 2011/8/19 21:03, Rémi Després 写道:
Yong, Rajiv,
Le 19 août 2011 à 14:16, Rajiv Asati (rajiva) a écrit :
Yong,
Why is dIVI not included In the discussion ?
In my understanding, differences between dIVI and the proposal of
draft-murakami-softwire-4v6-translation-00 are minimal.
They both
+1.
The RFP angle is an important one, Simon.
Cheers,
Rajiv
Sent from Phone
On Aug 19, 2011, at 8:57 AM, Simon Perreault simon.perrea...@viagenie.ca
wrote:
On 2011-08-19 05:19, Tetsuya Murakami wrote:
draft-murakami-softwire-4rd
draft-murakami-softiwire-4v6-translation
I think it
We mentioned 'tunneling vs translating'. This should cover it.
Alain.
Sent from my iPad
On Aug 19, 2011, at 8:16 AM, Rajiv Asati (rajiva) raj...@cisco.com wrote:
Yong,
Why is dIVI not included In the discussion ?
Could you please clarify?
Cheers,
Rajiv
Sent from Phone
On
It doesn't, IMO. In fact, I beg to say that it is unfair mention
'tunneling vs translating' as a blanket statement, since we have known
all along that a sane 4v6 solution would likely involve translating
(44), no matter what.
Moreover, it is reasonable to call out all stateless 4v6 options, not
When the RFP is coming from Best Buy for a consumer device, you want fewer
alternatives.
- Mark
On Aug 19, 2011, at 9:25 AM, Rajiv Asati (rajiva) wrote:
+1.
The RFP angle is an important one, Simon.
Cheers,
Rajiv
Sent from Phone
On Aug 19, 2011, at 8:57 AM, Simon Perreault
On 2011-08-19 11:21, Mark Townsley wrote:
When the RFP is coming from Best Buy for a consumer device, you want fewer
alternatives.
That's overly simplifying.
I would expect the standard bodies such as Cable Labs, BBF, 3GPP, etc.
to specify applicability of translation vs encapsulation to
Precisely. Fewer alternatives means cheaper, simpler hardware that is
ultimately required to run the software necessary to support the features. A
myriad of options whether complex or not, is not that.
--Tom
On Aug 19, 2011, at 11:21 AM, Mark Townsley wrote:
When the
Hi Marc,
I am having trouble to see how this thing could be stateless?
Also I don't see why we should, in view of NAT64 which is already standardized
and there are implementations, why not use it?
Of course no offense to my friend Xing Li.
Regards,
Behcet
Particularly when targeting the
The SOFTWIRE WG will hold a face-to-face interim meeting in Beijing,
China on September 26-27, 2011. Below please find more information from
the SOFTWIRE chairs.
--
Hi folks,
We, softwire wg chairs, in agreement with our ADs, are announcing
an interim meeting in Beijing on September
Le 19 août 2011 à 17:11, Mark Townsley a écrit :
On Aug 19, 2011, at 5:17 AM, Rémi Després wrote:
Also, one of his slides has 4rd aka Stateless DS-lite. He knows, as you
know, that I had expressed strong opposition to this badly reductive view
(DS lite is hub and spoke, has no NAT in
On 8/19/11 4:17 AM, Satoru Matsushima wrote:
This way no address translation is needed, just ports needs to be
redirected to right ones.
It seems to me that no modification for any system call, correct?
AFAIK, Nejc insists some system call modification, bind(), etc.,
Yes, if CPE is doing
+1.
It is fair enough.
But the operators will probably meet more difficulties to change v4 CPE than to
change v6 CPE. (Maybe irrelevant to this thread.)
Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html
-Original Message-
From: softwires-boun...@ietf.org
Dear Brian,
won't work. But in my world, A+P-enabled hosts are connected to the
IPv6 network directly.
And how will that support legacy SOHO LANs?
It will not, because I don't have a legacy SOHO LAN. If I have legacy
SOHO LAN, I can use (optional) NAT44.
Nejc
Dear Gang,
What if in my deployment scenario there are no legacy end hosts? What
if all hosts implement A+P-style port ranges?
I'm with Nejc here. A+P/4rd/... do not require NAT44.
And then, how many hosts could support what if in the wild
I don't see why this is important. Anyway, the
Dear Gang,
NOT PRACTICABLE has two meanings.
1) Restricted port aware host is relatively few case
Since we are not developing mechanisms for the period of the next few
months, I don't think this argument is relevant. Long term, there
might (hopefully) be more such hosts.
2) Socket need to
On 2011-08-20 09:18, Nejc Škoberne wrote:
Dear Brian,
won't work. But in my world, A+P-enabled hosts are connected to the
IPv6 network directly.
And how will that support legacy SOHO LANs?
It will not, because I don't have a legacy SOHO LAN. If I have legacy
SOHO LAN, I can use
Dear Rémi,
Whether Encapsulation and Double-translation methods will remain in separate
drafts or might be regrouped in a single one including their comparison is, as
far as I am concerned, an open question (neither in favor nor against).
Not being in favor of a wide palette of different
It will not, because I don't have a legacy SOHO LAN. If I have legacy
SOHO LAN, I can use (optional) NAT44.
Exactly, resulting in NAT444 . But if I'm forced to use NAT444
via a 4 in 6 tunnel anyway, A+P is pointless.
I don't think you understood what I was saying. There is no need for
Because of what RFC6333 says, suggesting NOW that solutions that don't need
NATs are variants of DS-lite is a sure way to confuse people.
+1
Nejc
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
On Aug 19, 2011, at 8:04 PM, Nejc Škoberne wrote:
Because of what RFC6333 says, suggesting NOW that solutions that don't need
NATs are variants of DS-lite is a sure way to confuse people.
Then we're already confused:
http://tools.ietf.org/html/draft-boucadair-softwire-cgn-bypass-03
- Mark
On Aug 19, 2011, at 1:08 PM, Rémi Després wrote:
Le 19 août 2011 à 17:11, Mark Townsley a écrit :
On Aug 19, 2011, at 5:17 AM, Rémi Després wrote:
Also, one of his slides has 4rd aka Stateless DS-lite. He knows, as you
know, that I had expressed strong opposition to this badly
2011/8/19 Rajiv Asati (rajiva) raj...@cisco.com
It doesn't, IMO. In fact, I beg to say that it is unfair mention
'tunneling vs translating' as a blanket statement, since we have known
all along that a sane 4v6 solution would likely involve translating
(44), no matter what.
Moreover, it is
33 matches
Mail list logo
