, could be to add in view of doubts
expressed about RFC4821 practicability after negligible.
RD
Tom Taylor
On 16/11/2014 11:55 AM, Rémi Després wrote:
Hi Tom,
If a statement proceeds to be added, I propose something like this in the
introduction:
Warning: on paths that traverse MAP
17 nov. 2014 14:45, Ted Lemon ted.le...@nominum.com :
On Nov 17, 2014, at 3:25 AM, Rémi Després despres.r...@laposte.net wrote:
If this is true (which isn’t clear to me at all ) wouldn’t RFC4821
deprecation be the right action?
Without that, considering here, implicitly, that RFC4821
Le 16 nov. 2014 à 04:54, Ted Lemon ted.le...@nominum.com a écrit :
On Nov 15, 2014, at 10:24 AM, Rémi Després despres.r...@laposte.net wrote:
This seems to suggest that someone viewed this issue had been a factor in
the coin toss.
No one did AFAIK, and certainly not me.
But this isn’t
Hi Tom,
If a statement proceeds to be added, I propose something like this in the
introduction:
Warning: on paths that traverse MAP-T IPv6 networks, ICMP-independent PathMTU
Discovery, as specified in [RFC 4821], ceases to be reliable. (This is because
DF=1/MF=1 combination, used in [RFC
15 nov. 2014 01:40, Ted Lemon ted.le...@nominum.com :
On Nov 14, 2014, at 12:22 PM, Rémi Després despres.r...@laposte.net wrote:
If this is acceptable to whoever wants to deploy MAP-T, in due knowledge of
its experimental status, it is not AFAIK acceptable in a standard.
I do hear your
nov. 2014 01:40, Ted Lemon ted.le...@nominum.com :
On Nov 14, 2014, at 12:22 PM, Rémi Després despres.r...@laposte.net wrote:
If this is acceptable to whoever wants to deploy MAP-T, in due knowledge
of its experimental status, it is not AFAIK acceptable in a standard.
I do
15 nov. 2014 12:32, Ted Lemon ted.le...@nominum.com :
It is true that double translation has the problem that the DF bit is not
communicated through. This is a limitation of the MAP-T specification.
I've asked the authors about this, and they did not deny that this
limitation exists,
13 nov. 2014 22:40, Ted Lemon ted.le...@nominum.com :
On Nov 13, 2014, at 11:32 AM, Rémi Després despres.r...@laposte.net wrote:
(a) Incompatibility with path MTU discovery (standard-track RFC4821) is, in
my understanding, sufficient a reason to keep MAP-T experimental.
Pretty much
14 nov. 2014 20:35, Ted Lemon ted.le...@nominum.com :
On Nov 14, 2014, at 12:49 AM, Rémi Després despres.r...@laposte.net wrote:
- Only MAP-T lacks transparency to the IPv4 DF bit.
So your concern is that if fragmentation at the translator results in an IPv6
packet that is larger than
Le 13 nov. 2014 à 01:46, Ted Lemon ted.le...@nominum.com a écrit :
On Nov 11, 2014, at 11:46 PM, Rémi Després despres.r...@laposte.net wrote:
What makes objections to become blocking may be unclear, but I hope that the
above will be enough for the WG to maintain its old and wise consensus
Hi Edwin,
Thanks for sharing you views.
More comments below.
...
a result of the directorate reviews and the IESG review, it became
clear that the plan to advance MAP-T as experimental didn't make sense.
AFAIK, not at all as clear as you say:
- If both MAP-E and MAP-T would become standard,
13 nov. 2014 21:00, Ted Lemon ted.le...@nominum.com :
On Nov 13, 2014, at 6:29 AM, Rémi Després despres.r...@laposte.net wrote:
If the IESG, now proposes 2 standards instead of 1, that’s a choice I view
as based on a misunderstanding.
The IESG proposes one standard with three profiles
Hi Ted,
You are right in that an old decision may always be revisited before casting it
in concrete.
Yet, changing an old decision has to be done carefully, especially if
consequences of the change haven’t been documented.
Comments below suggest that wisdom is rather to maintain the old
Hi, Ole,
FWIW, a look at
https://tools.ietf.org/html/draft-ietf-softwire-4rd-09#section-4.6.3 might be
helpful.
Cheers,
RD
Le 15 oct. 2014 à 15:27, Ole Troan otr...@employees.org a écrit :
Ted, et al,
there are good arguments going both ways, so apologies for my changing
opinion here.
Dear Sheng,
This is to confirm on the WG list what I discussed with you concerning 4rd and
NAT64+.
1.
Adaptation of the 4rd draft to 6man precluding IID-range reservations, appears
to have been incomplete:
- Without a 4rd IID-range reservation, a NAT64+ can no longer distinguish
4rd-capable
on
which the WG, and in particular a knowledgeable contributor like Med, is well
placed to conclude .
Regards,
RD
Thanks
Suresh
On 04/09/2013 11:58 AM, Rémi Després wrote:
Dear Med, dear all,
I carefully checked France Telecom's IPR statement we just received about
4rd.
For reasons
Le 2013-04-10 à 11:51, Simon Perreault simon.perrea...@viagenie.ca a écrit :
Le 2013-04-10 09:23, Rémi Després a écrit :
In my understanding, this justifies that an IPR statement that doesn't
concern an RFC (with due understanding of initiators of the statement),
should be deleted by its
Dear Med, dear all,
I carefully checked France Telecom's IPR statement we just received about 4rd.
For reasons detailed below, I found that none of the three listed patents
applies to 4rd.
Could you please, Med, check the technical analysis and, if we reach common
understanding, see to it that
2013-02-28 15:34, Qiong bingxu...@gmail.com :
...
Currently, the title of this draft is still MAP only, as we have not found a
good term to call MAP-E, MAP-T and 4rd-u. So we would like to get advice from
the working group to address this problem.
Thanks to Qiong for raising this question
Hello, Tomek,
Two comments related to recent discussions:
1. The PSID-len parameter of section 4.5 MUST NOT be used in BMRs that apply to
several CEs (the general case in stateless use of MAP). If 1:1 mapping must be
covered by MAP (next point), this should be noted in the text.
2. Whether
2013-02-17 03:03, Qiong bingxu...@gmail.com :
...
It is my opinion that we've discussed this 1:1 mode many many times
before, and at each time concluded that a) it is a natural characteristic
of MAP ii) it would actually require *more text* (and complexity) to
remove it.
Sorry I can
2013-02-14 16:30, Rajiv Asati (rajiva) raj...@cisco.com :
My vote is to keep 1:1 mode in MAP. Removing it just doesn't make sense
Your point, similar to that of Ole, is that 1:1 is intrinsic to the design.
Even if not explicitly stated, it therefore cannot be removed from it.
To put an end
2013-02-15 10:03, Wojciech Dec (wdec) w...@cisco.com :
...
It is my opinion that we've discussed this 1:1 mode many many times
before, and at each time concluded that a) it is a natural characteristic
of MAP ii) it would actually require *more text* (and complexity) to
remove it.
Would you
Le 2013-02-15 à 11:16, Wojciech Dec (wdec) w...@cisco.com a écrit :
On 15/02/2013 10:11, Rémi Després despres.r...@laposte.net wrote:
2013-02-15 10:03, Wojciech Dec (wdec) w...@cisco.com :
...
It is my opinion that we've discussed this 1:1 mode many many times
before, and at each
neutral.)
Regards,
RD
On 15/02/2013 12:06, Rémi Després despres.r...@laposte.net wrote:
...
It is thus clear that, if section 7.4 and examples 4 and 5 are deleted
from the MAP draft, *no more text* is NEEDED in the draft itself.
Applicability of MAP and of other solutions to 1:1 can be clarified
Le 2013-02-15 à 14:40, Wojciech Dec (wdec) w...@cisco.com a écrit :
On 15/02/2013 14:30, Rémi Després despres.r...@laposte.net wrote:
2013-02-15 12:16, Wojciech Dec (wdec) w...@cisco.com :
Remi,
The question Ole posed still stands:
- what does remove MAP 1:1 mode mean
Le 2013-02-15 à 16:14, Wojciech Dec (wdec) w...@cisco.com a écrit :
On 15/02/2013 14:51, Rémi Després despres.r...@laposte.net wrote:
We've previously established consensus that MAP supports 1:1 mode (it
likely happened at the meeting after you bid farewell to the group).
Suresh can
2013-02-14 12:12, Ole Troan o...@cisco.com:
Med,
To start with, there was no consensus to include MAP1:1 in the MAP spec.
Unless I'm mistaken, objection to include that mode in the base MAP spec was
raised several times in the mailing list. It was mainly raised by authors of
Lw4o6 but
2013-01-29 19:54, Ole Troan otr...@employees.org :
Remi,
...
can we please hold back a little and let other people in the working group
voice their opinion?
To make progress, I feel it should be acceptable to continue to:
- ask for clarifications on some points that IMHO remain obscure
Le 2013-01-30 à 10:04, Ole Troan otr...@employees.org a écrit :
Remi,
can we please hold back a little and let other people in the working group
voice their opinion?
To make progress, I feel it should be acceptable to continue to:
- ask for clarifications on some points that IMHO
Le 2013-01-30 13:47, Ole Troan o...@cisco.com :
Tom,
[...]
I don't at all see why moving the port mapping algorithm out of the
document would make things simpler. it would make it a lot more
complex. then you'd end up with having to support many different port
algorithms.
My
2013-01-28 17:36, Senthil Sivakumar (ssenthil) ssent...@cisco.com :
...
Yet, operators have the constraint of RFC 4291 that For all unicast
addresses, except those that start with the binary value 000, Interface
IDs are required to be 64 bits long and to be constructed in Modified
EUI-64
2013-01-30 16:52, Tom Taylor tom.taylor.s...@gmail.com :
On 30/01/2013 9:56 AM, Rémi Després wrote:
Le 2013-01-30 13:47, Ole Troan o...@cisco.com :
Tom,
[...]
[Ole said:]
I'm fine with fixing a to 4.
if an end user needs well known ports, give her a full address.
[Rémi said
The key is keep it simple, with neither IPv4 addresses nor PSIDs in MAP-E
IIDs.
More explanations below.
2013-01-28 14:51, Wojciech Dec wdec.i...@gmail.comt :
Hi,
the IPv4 and PSID in the IID are particularly useful in cases of address
independence (ie 1:1). As said previously, the
2013-01-29 10:50, Ole Troan otr...@employees.org :
...
(c) Once the rule is looked at, getting the PSID is easy (no more magic
needed than to get find the PSID length ;-)).
unless you are in 1:1 mode.
There is a point here which AFAIK has never been discussed before.
(A reference is
Hi, Linda,
2013-01-29 à 07:54, wang.c...@zte.com.cn a écrit :
Hi,Remi
softwires-boun...@ietf.org 写于 2013-01-29 00:16:32:
Senthil,
2013-01-2815:24, Senthil Sivakumar (ssenthil) ssent...@cisco.com :
I believe the prefix length 64 should be allowed.
It is
Ole,
Thanks for the clarification.
More comments inline.
2013-01-29 à 18:14, Ole Troan otr...@employees.org :
Remi,
(c) Once the rule is looked at, getting the PSID is easy (no more magic
needed than to get find the PSID length ;-)).
unless you are in 1:1 mode.
There is a point here
On 26/01/2013 5:50 AM, Rémi Després wrote:
Hi, Senthil,
2013-01-25 à 21:20, Senthil Sivakumar (ssenthil) ssent...@cisco.com :
On 1/25/13 1:09 PM, Tom Taylor tom.taylor.s...@gmail.com wrote:
We have two choices on this one:
a) prohibit the use of an end user IPv6 prefix of length
Le 2013-01-27 à 23:07, Tom Taylor tom.taylor.s...@gmail.com a écrit :
The examples in my previous note sort of provided backing for my view that
the MAP endpoint IPv6 prefix can be limited to a maximum of a /64, thus
making the IID fully conformant both to RFC 4291 and to RFC 6052.
Le 2013-01-28 à 10:16, Ole Troan otr...@employees.org a écrit :
Remi, Tom,
Rémi has a point. RFC 4291 doesn't seem to leave wiggle room. Section 2.5.1
says:
(*)
For all unicast addresses, except those that start with the binary
value 000, Interface IDs are required to be 64 bits long
Senthil,
2013-01-2815:24, Senthil Sivakumar (ssenthil) ssent...@cisco.com :
I believe the prefix length 64 should be allowed.
It is upto the
operator to choose the prefix length of their choice.
Agreed.
No one suggest to say the contrary.
Yet, operators have the constraint of RFC 4291
Le 2013-01-28 à 17:30, Ole Troan otr...@employees.org a écrit :
Remi,
I believe the prefix length 64 should be allowed.
It is upto the
operator to choose the prefix length of their choice.
Agreed.
No one suggest to say the contrary.
Yet, operators have the constraint of RFC
Hi, Senthil,
2013-01-25 à 21:20, Senthil Sivakumar (ssenthil) ssent...@cisco.com :
On 1/25/13 1:09 PM, Tom Taylor tom.taylor.s...@gmail.com wrote:
We have two choices on this one:
a) prohibit the use of an end user IPv6 prefix of length greater than 64
bits;
I would think that is
2013-01-24 17:27, Ole Troan otr...@employees.org :
hi,
can we please keep discussion on the list. not via the issue tracker?
- the issue tracker was AFAIK created by the chairs to be used.
- I was answering a new input from Ole on the issue tracker itself, and
containing a question (see
Hello all,
RFC 6751 is now available at http://tools.ietf.org/html/rfc6751).
It describes a new tunneling solution for providers to offer IPv6 service
behind IPv4-only CPEs. Like 6rd, 6a44 is a provider-local solution using
provider allocated prefixes. As such, it has over Teredo an advantage
Gang,
I think you are on a wrong track here.
1. In Vancouver it was decided that MAP-E would be standard track, and both
MAP-T and 4rd experimental. There is no longer any way to prevent those who
want experimental MAP-T to have it.
2. The argument against ACLs is also an argument against 4rd.
2012-09-07 à 10:19, Maoke:
i share the same view with Remi. and ACL is not the only reason that MAP-T is
needed. - maoke
Yes, we do agree that work on experimental MAP-T can continue in Softwire (as
decided in Vancouver)
But lets avoid confusion concerning my position: I am not personally
Suresh,
May I suggest that, in in the future, the MAP-E specification be in a MAP-E
document rather than in a generic MAP document (e.g. in
draft-ietf-softwire-map-e-00).
This will become particularly relevant when the MAP-T document will follow.
Regards,
RD
Début du message réexpédié :
Hi, Suresh,
2012-08-08 00:02, Suresh Krishnan :
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 room was in favor of MAP-E as the basis for the proposed
standard stateless
Le 2012-08-08 à 16:13, Rajiv Asati (rajiva) a écrit :
+1
I also support MAP-E and MAP-T, as Maglione pointed out. We need to be
respectful of the design team that produced MAP based on consideration and
requirements.
Not to forget that MAP-T (unlike others) has already been deployed.
Le 2012-07-27 à 16:20, Wojciech Dec a écrit :
On 25 July 2012 16:13, Rémi Després despres.r...@laposte.net wrote:
Le 2012-07-25 à 15:59, Wojciech Dec (wdec) a écrit :
On 25/07/2012 15:47, Rémi Després despres.r...@laposte.net wrote:
take it to 6man.
6man has
Le 2012-07-27 à 16:55, Tomek Mrugalski a écrit :
On 24.07.2012 15:10, Rémi Després wrote:
Hi, Tomek,
Hi Remi. hi all,
Since you are the known DHCP expert in Softwire concerning stateless
Thank you for your kind words. I just know DHCPv6 a bit, but I
definitely don't consider myself
Le 2012-07-24 à 12:46, Ole Trøan a écrit :
1. No, 4rd doesn't have the same problem as MAP concerning sites that use
subnet 0.
Wojciech, if you see a reason why a site should renumber its subnet 0 to
use 4rd, please explain.
because no-one will ever do this?
Assuming that details that
Le 2012-07-25 à 09:55, Ole Trøan a écrit :
Remi,
because no-one will ever do this?
Assuming that details that follow mean that an expert can configure a node
with an address that isn't unauthorized by any RFC, and in particular a
4rd-reserved address, that's acknowledged.
But
Le 2012-07-25 à 15:56, Wojciech Dec (wdec) a écrit :
On 25/07/2012 15:47, Rémi Després despres.r...@laposte.net wrote:
Le 2012-07-24 à 12:46, Ole Trøan a écrit :
1. No, 4rd doesn't have the same problem as MAP concerning sites that
use
subnet 0.
Wojciech, if you see a reason why
Le 2012-07-25 à 15:59, Wojciech Dec (wdec) a écrit :
On 25/07/2012 15:47, Rémi Després despres.r...@laposte.net wrote:
take it to 6man.
6man has to be involved, sure, but Softwire should first be clear about
the purpose, and possible drawbacks if any.
If you see such drawbacks
Hi, Tomek,
Since you are the known DHCP expert in Softwire concerning stateless solutions,
could you kindly review section 4.8 of the 4rd-03 draft, and comment on the ML
its use of DHCPv6?
(Doing so, of course, will not prejudge what the WG will decide concerning
MAP-T+E vs 4rd.)
In
Hi, Wojciech,
2012-07-20 12:56, Wojciech Dec:
Hi Maoke,
...
therefore i am objective of introducing PSID into the rule and making the
architecture stateless only in wording.
If you mean that by having PSID as part of the rule, moves MAP from being
stateless to stateful, then that's a
Hello, all,
tools.ietf.org/html/draft-despres-softwire-stateless-analysis-tool-02 has been
posted.
As said in the abstract:
This document proposes a discussion tool for the Softwire meeting at IETF 84
in Vancouver.
Significant differentiating features between the MAP approach (proposed
Hi, Behcet,
In the abstract, customers is intended to mean customers *of operators*
(CPEs, not end-user hosts).
This can be clarified by, for example, replacing customers by customer
sites.
Agreed?
Thanks,
RD
Le 2012-07-11 à 21:41, Behcet Sarikaya a écrit :
Hi Remi,
I was reading this
2012-07-10 à 20:34, Suresh Krishnan :
...
Once the document comes under wg change control, it is the
consensus of the wg that will drive it further. If there is wg consensus
to include 4rd related text in this document either in addition to or in
lieu of the MAP related text, that is what
Hi, Suresh,
This draft contains valuable advices which can apply to 4rd as well as to
MAP-T+E, but is exclusively MAP oriented.
As such, I find it premature to move it to WG-draft status.
If 4rd is chosen for standardization, adapting this deployment draft to it
looks easy.
I therefore
2012-07-10 13:03, Maoke :
hi Remi,
2012/7/10 Rémi Després despres.r...@laposte.net
Hi, Suresh,
This draft contains valuable advices which can apply to 4rd as well as to
MAP-T+E, but is exclusively MAP oriented.
surely it is a MAP-oriented stuff as only the MAP-T+E are considered
The following email, sent by lorenzo to the mailing list didn't reach it
because he isn't registered in Softwire.
Upon his request, here is a retransmission.
Regards,
RD
De : Lorenzo Colitti lore...@google.com
Date : 2012-07-06 10:59
À : Rémi Després despres.r...@laposte.net
Cc : softwires
2012-07-06 06:33, Suresh Krishnan :
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.
When I asked Alain whether WG drafts on 4rd and MAP should be Experimental or
Suresh,
For consistency, we do need a complement to map-01 which shows proposed DHCPv6
formats.
= Support to have it as WG draft, provided:
- the accepted status status is the same for map and 4rd documents (still to be
determined AFAIK).
- It is understood that the WG plans to choose which of
Hi all,
There has been discussions, during IETF 83 and after, to warn that, in some
circumstances, direct TCP over IPv6 can be significantly faster than
TCP/IPv4/IPv6.
A cc is sent to Lorenzo, because he privately reported some direct knowledge of
the subject (I personally have none).
?
Regards,
RD
De : Rémi Després despres.r...@laposte.net
Date : 2012-06-19 15:28
À : Softwires WG softwires@ietf.org
Objet : Novelty in draft-ietf-softwire-4rd-01
Dear all,
The main difference between -00 and -O1 concerns protection against address
or protocol corruption during 4rd
Le 2012-06-28 à 17:16, Suresh Krishnan a écrit :
Hi all,
There has been quite a bit of traffic on the mailing list as to
whether the current map and 4rd drafts actually represent wg consensus.
In order to clear the air around this, we have asked the map and the 4rd
editors to revert to the
(ability to combine complete IPv4 transparency with IPv6-ACL compatibility)
How to introduce this 3rd choice in WG documents is AFAIK in chairs' hands.
Regards,
RD
Best regards,
--satoru
On 2012/06/23, at 1:52, Rémi Després wrote:
Yong, Suresh, Ralph,
For mesh stateless v4/v6, we
Le 2012-06-26 à 08:04, Wojciech Dec a écrit :
On 25 June 2012 17:28, Rémi Després despres.r...@laposte.net wrote:
2012-06-25 à 16:24, Wojciech Dec:
...
The updated MAP draft does not change the MAP architecture nor its
technical underpinnings. In fact there are no changes, bar
2012-06-26 à 09:37, Wojciech Dec:
On 26 June 2012 09:13, Rémi Després despres.r...@laposte.net wrote:
Le 2012-06-26 à 08:04, Wojciech Dec a écrit :
On 25 June 2012 17:28, Rémi Després despres.r...@laposte.net wrote:
...
Having asked several times for a list of substantial evolutions from
2012-06-26 à 10:50, Wojciech Dec:
On 26 June 2012 10:37, Rémi Després despres.r...@laposte.net wrote:
2012-06-26 à 09:37, Wojciech Dec:
On 26 June 2012 09:13, Rémi Després despres.r...@laposte.net wrote:
Le 2012-06-26 à 08:04, Wojciech Dec a écrit :
On 25 June 2012 17:28, Rémi
2012-06-25 à 16:24, Wojciech Dec:
...
The updated MAP draft does not change the MAP architecture nor its technical
underpinnings. In fact there are no changes, bar editorial to the normative
parts of MAP,
Having asked several times for a list of substantial evolutions from previous
MAP
Yong, Suresh, Ralph,
For mesh stateless v4/v6, we have so far a choice between only two solutions,
MAP as is and 4rd.
On can hope that the consensus that couldn't be reached in Paris will be
achievable in Vancouver, but this isn't sure, each camp keeping its own
expectation.
Looking at recent
this to softwire if useful.)
More opinions from the WG?
Regards,
RD
On 2012-06-19 08:36, Rémi Després wrote:
Hi, Brian,
In the still progressing 4rd design, flow labels happen to be
a convenient tool to maintain, after 4rd domain traversal,
IPv4-like protection of addresses and protocol
Dear all,
The main difference between -00 and -O1 concerns protection against address or
protocol corruption during 4rd-domain traversal:
Problem: the CNP only protected IPv4 addresses of full-or-shared-address CEs?
In particular, they didn't protect IPv4 addresses embedded in BR-destined IPv6
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
Peng,
2012-06-07 à 16:04, Peng Wu:
Hi Ole and all,
Thank you all for the discussions on this topic, as well as sharing
your opinions during the offline discussions in the last couple of
days. Let me try to summarize.
I understand that we MAY adapt MAP to be 4over6-like, or even DS-lite
Qiong, all,
Le 2012-06-07 à 16:23, Qiong a écrit :
Hi Ole,
On Thu, Jun 7, 2012 at 4:48 PM, Ole Trøan otr...@employees.org wrote:
I think we should still keep the initial feature of these solutions.
all the proposed solutions, including DS-lite shares a large set of
commonalities.
Maoke,
Please see comments inline.
2012-06-04 04:35, Maoke:
sorry for the late reply.
2012/5/23 Simon Perreault simon.perrea...@viagenie.ca
(Did you intend to send this to the WG?)
thanks for reminding :) i did reply but not reply-all.
On 2012-05-22 21:38, Maoke wrote:
My
Support.
RD
Le 2012-05-27 à 16:28, Yong Cui a écrit :
Hi folks,
This is a wg last call on draft-ietf-softwire-stateless-4v6-motivation-01.
http://datatracker.ietf.org/doc/draft-ietf-softwire-stateless-4v6-motivatio
n/
As usual, please send editorial comments to the authors and
2012-05-30 15:55, Ole Trøan:
public 4over6 is exactly the same as MAP in hub and spoke mode with one
mapping rule per subscriber.
Could you clarify how this relates to the MAP-rule definition saying Each MAP
node in the domain has the same set of rules.
not touching the first bit of Hop Limit now. thanks!
regards,
maoke
2012/5/23 Rémi Després despres.r...@laposte.net
Hi Maoke,
Thank you for this quick reaction.
2012-05-22 03:54, Maoke :
hi Remi and other authors,
thanks a lot for updating the draft. semantics review
Hello, all,
The solution that, with Reinaldo Penno, Yiu Lee, Gang Chen, and Sheng Jiang, we
submit to the WG, as proposed standard for stateless IPv4 via IPv6, is now
available.
The acronym is now just 4rd as other proposals using it have all expired (4rd-E
and 4rd T).
As done for 6rd
Hi Maoke,
Thank you for this quick reaction.
2012-05-22 03:54, Maoke :
hi Remi and other authors,
thanks a lot for updating the draft. semantics review will follow and here i
only make an incomprehensive but quick response. please don't hesitate to
point out if i misunderstand.
i
Le 2012-05-04 à 12:08, Leaf yeh a écrit :
Jacni - Anyway, if generally we have a single target or design goal,…
There are many design goals here. What Ole said in this email is the solution
of Encapsulation Translation will meet the different ones, which sounds
mutually exclusive. Will
accepted by the group. Right?
That's the purpose of this question: will standard unicity be confirmed by the
WG an important criterion?
If you agree, we can resume this discussion when all specifications are
available.
Kind regards,
RD
Best Regards,
Leaf
From: Rémi Després
2012-05-03 à 10:38, Ole Trøan:
...
let us accept that the requirements for translation and the requirements for
encapsulation are mutually exclusive.
Agreed: each of E or T doesn't cover by itself all expressed requirements for a
stateless 4via6 solution.
The question that remains, however,
Maoke,
We haven't reached common understanding on tunnel and transparency yet.
Please see below.
2012-04-12 03:13, Maoke:
second point, on tunnel and transparency.
2012/4/11 Rémi Després despres.r...@laposte.net
6. The statement that double translation is also a sort of tunneling
2012-04-12 à 12:33, Maoke:
2012/4/12 Rémi Després despres.r...@laposte.net
Maoke,
We haven't reached common understanding on tunnel and transparency yet.
Please see below.
ok.
2012-04-12 03:13, Maoke:
second point, on tunnel and transparency.
2012/4/11 Rémi
Le 2012-04-12 à 18:15, Maoke a écrit :
hi Remi,
this acknowledges the part not belonging to technical issues.
2012/4/11 Rémi Després despres.r...@laposte.net
Maoke,
Good to see that at least one who has read the 4rd-u draft still considers
that technical considerations are worth
Maoke,
Good to see that at least one who has read the 4rd-u draft still considers that
technical considerations are worth working on.
Thanks.
IMHO, you did a great job to structure this (useful) discussion.
Here are quick comments/suggestions/corrections I propose:
4.1. (M2) Rather than
.
Your full name, your affiliation, your choice: YES or NO
Rémi Després, RD-IPtech, neither YES nor NO (both impossible)
Regards,
RD
Le 2012-04-11 à 15:44, Maoke a écrit :
postpone other parts, but focus on the checksum issue.
2012/4/11 Rémi Després despres.r...@laposte.net
5.4 Impact c. - it is true that, in the IPv6 packet of a tunneled ICMPv4
message, the ICMPv4 checksum doesn't ensure IPv6 address integrity
Le 2012-04-11 à 17:54, Maoke a écrit :
2012/4/12 Rémi Després despres.r...@laposte.net
Le 2012-04-11 à 15:44, Maoke a écrit :
postpone other parts, but focus on the checksum issue.
2012/4/11 Rémi Després despres.r...@laposte.net
5.4 Impact c. - it is true that, in the IPv6
Le 2012-04-10 à 07:35, GangChen a écrit :
Hello all,
I have tried to work hard and technically contribute to all documents:
MAP-algorithm, MAP-T, MAP-E, MAP-Deployment, 4rd-U, and also cosigned
with all of them. Please allow me to share some points here.
Basic idea of MAP algorithm were
Le 2012-04-10 à 09:59, Wojciech Dec a écrit :
On 10 April 2012 09:31, Rémi Després despres.r...@laposte.net wrote:
Le 2012-04-10 à 07:35, GangChen a écrit :
Hello all,
I have tried to work hard and technically contribute to all documents:
MAP-algorithm, MAP-T, MAP-E, MAP
, implicitly, or possibly both?
- How?
- Which tests have confirmed that it worked?
Answer by any one who asserts he or she understands how MAP works will be
welcome.
Thanks,
RD
De : Ole Trøan o...@cisco.com
Date : 2012-03-14 14:29
À : Rémi Després despres.r...@laposte.net
Cc : Tomasz
CEs are proposed to know
whether they must work in mesh or hub-an-spoke topology (even if MAP remains
experimental).
RD
-Woj.
On 10 April 2012 12:01, Rémi Després despres.r...@laposte.net wrote:
Wojciech,
This isn't answers to questions I asked.
They remain open.
RD
Le 2012-04
1 - 100 of 416 matches
Mail list logo
