Hi Dapeng,
A state maintained in the endpoint does not make the solution stateful, see
this excerpt from RFC1958:
This principle has important consequences if we require applications
to survive partial network failures. An end-to-end protocol design
should not rely on the maintenance
I would prefer IETF more strict about what accurate terminology we are
using other than favorite. At this moment this document go through
working group last call which I have reviewed, and believe it should
be Revised for not misleading other people. Thanks for your
suggestion.
Regards,
Dapeng
Hi Behcet,
I failed to understand the point you are trying to make.
The current situations is:
* this document provides multicast extension to deliver multicast to DS-Lite
serviced customers
* we rely on multicast capabilities, as such no AMT-like considerations are
included
* the proposed
Re-,
I was answering to your last proposed wording to include the port translation
in the host. Except that change, all your proposed changes are included in my
local copy:
* The title has been updated as your requested
* The introduction has been updated.
Cheers,
Med
-Message
Hello Med,
Yes, we are almost converged on this final update.
As you said here, there still need port translation in the host, that
still state in the host. we need clarify that in this document for
other readers.
Best Regards,
Dapeng Liu
2012/6/11, mohamed.boucad...@orange.com
On 9 June 2012 05:35, Qi Sun sunqi.csnet@gmail.com wrote:
Hi Ole,
In your previous Email you wrote,
in MAP you do all of that with one single DHCPv6
option...
IMHO, that's because the one DHCPv6 option contains so many KINDS of
information (e.g. PSID, BR's prefix or address, see
2012/6/11, Rémi Després despres.r...@laposte.net:
Le 2012-06-11 à 09:32, liu dapeng a écrit :
Hello Med,
Yes, we are almost converged on this final update.
As you said here, there still need port translation in the host, that
still state in the host.
Note that these states are
Ole,
Thank you for this update on what is meant by MAP today.
Which parameters are advertised to CEs will be completely clear, I suppose,
when the DHCPv6 document is also available, but the draft contains IMHO useful
clarifications.
Two immediate points:
- Last sentence of page 8 is DNS64
Hi Yiu,
Works for me. Thanks.
Cheers,
Med
-Message d'origine-
De : Lee, Yiu [mailto:yiu_...@cable.comcast.com]
Envoyé : lundi 11 juin 2012 16:54
À : BOUCADAIR Mohamed OLNC/NAD/TIP; liu dapeng
Cc : softwires@ietf.org; Yong Cui
Objet : Re: [Softwires] WG last call on
Hi Med,
Thanks for your kind reply. I was talking about
http://tools.ietf.org/html/draft-sarikaya-softwire-dslite6rdmulticast-00
(which is now expired, I'll explain why below)
Profiting the occasion, let me clarify that the chairs, Alain
initially asked the two drafts to be merged.
We favored
Woj,
On Mon, Jun 11, 2012 at 5:10 PM, Wojciech Dec wdec.i...@gmail.com wrote:
There is basic question regarding this draft, one that has also been raised
at previous WG meetings: why is it needed?.
It's actually written in section 4 of the draft.
There is a deeper issue here: This draft seems
On 6/10/2012 11:15 PM, mohamed.boucad...@orange.com wrote:
Hi Behcet,
I failed to understand the point you are trying to make.
The current situations is:
* this document provides multicast extension to deliver multicast to DS-Lite
serviced customers
But not only DS-Lite.
* we rely on
On 6/11/2012 1:21 PM, Tina TSOU wrote:
If we r looking for a generic encapsulation for multicast transition, here it
is.
http://datatracker.ietf.org/doc/draft-tsou-softwire-encapsulated-multicast/
In a way, your draft is even more generic Tina. There are also some
differences.
You're talking
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Softwires Working Group of the IETF.
Title : Motivations for Carrier-side Stateless IPv4 over IPv6
Migration Solutions
Author(s) : Mohamed Boucadair
14 matches
Mail list logo
