Yiu,
I am not talking about whether a MAP-domain should support 1 or N CEs.
What I am trying to say is MAP-E 1:1 requires the BR to know per
subscriber information and the operator must pre-provision per-subscriber
based rules to every BR in the same domain. In addition, the BR can't use
On 2012/11/12, at 11:11, Ole Trøan wrote:
Yiu,
From my perspective, the argument is not whether two protocols are
identical or not. I found MAP-E 1:1 is a stateful solution. I found it odd
to make it part of MAP-E which was originally decided a stateless solution.
look at it as a
Hi Suresh,
I am in favor of both.
Thanks,
Tetsuya
On 2012/09/24, at 21:45, Suresh Krishnan wrote:
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
Support.
- Tetsuya
On 2012/07/05, at 21:33, Suresh Krishnan wrote:
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. Please state whether or not you're in favor of the
adoption
Hi Peng,
I think it is just example.
In case of this example, I think the standard of OSPF can't allow to use it for
only inter-area routing. This standard can also allow to use it within only
area 0. I think sometimes multiple solutions could be applied to solve the same
problem. In case of
)
...
But this is the implementation/deployment choice. So, from the standard
perspective, it might be good to merge H solution to MAP which has already
merged both E and T.
Thanks,
Tetsuya Murakami
On 2012/06/23, at 1:52, Satoru Matsushima wrote:
Dear Remi,
Thank you for a kind offer
. If you are saying
that, do you assume how many entries should be existed in the table in order to
call it to the state. From the implementation perspective, even though there
are 1000 entries in the table, the problem is just how much memory is
needed.
Thanks,
Tetsuya Murakami
On 2012/06
implementation does not
maintain the state for each entry.
Thanks,
Tetsuya Murakami
On 2012/06/25, at 2:27, Tetsuya Murakami wrote:
Hi Qi,
Even though there are a bunch of mapping rules, each mapping rule has no state.
Since each mapping rules is set manually, BR does not maintain each mapping
rule
only. So, our
implementation can allow 1:1 as well as N:1.
Thanks,
Tetsuya Murakami
On 2012/06/25, at 7:24, Wojciech Dec wrote:
Hi,
taking a step back to discuss some items in more detail, and hopefully move
this discussion forward:
1. Domain size
The MAP architecture does not prescribe
publish both as
standard track.
Answering NO to this question means you want to see both advance on the
standard track.
Tetsuya Murakami, IP Infusion: YES
(hubspoke model).
Thanks,
Tetsuya Murakami
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
transport instead of the existing
tunneling/translation.
Thanks,
Tetsuya Murakami
On 2012/04/01, at 11: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 4rd-u nodes. So then I suggest that remove checksum
neutrality function from the document.
cheers,
--satoru
On 2012/03/28, at 0:42, Tetsuya Murakami wrote:
Hi Remi,
Thank you for having the informational meeting of 4rd-u. I can understand
4rd-u very much.
As you mentioned
the packet
without any change of the existing IPv6 stack.
I think MAP/4rd-u are transition technology and so it is good to eliminate any
impact on the existing implementation of IPv6 stack as much as possible.
Thanks,
Tetsuya Murakami
On 2012/03/26, at 11:57, Rémi Després wrote:
Hi, all,
With some
address in case of MAP-E because the derived CE IPv6
address should be the tunnel end-point address on the CE. So, the received
packet should be discarded or not processed as MAP-E packet.
Thanks,
Tetsuya Murakami
I'm looking forward to your reply~
Best Regards,
Qi Sun
Tsinghua
Support. It is worth to adopt these drafts as WG drafts.
Thanks,
Tetsuya
On 2012/01/30, at 3:31, Ole Trøan wrote:
hi,
the MAP (Mapping of address and port) design team has now written and
published the following sets of drafts.
the base document (port mapping algorithm):
Hi Alain and Yong,
Could you please assign 10min slot for 4rd encapsulation draft
(draft-murakami-softwire-4rd)?
Thanks,
Tetsuya Murakami
On 2011/11/04, at 5:26, Alain Durand wrote:
If you want to present during the Softwire meetings in Taipei and you have
not yet sent me or Yong a request
value in the last 64bit of IPv6 destination address. From the
developer point of view, I would like to utilize the existing implementation as
much as possible.
Thanks,
Tetsuya Murakami
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org
additional CPU cycles per packet are required at CE in order to
embed the full IPv4 address (and port-set id) in the last 64bit of the IPv6
address.
Thanks,
Tetsuya Murakami
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman
Hi,
We posted an update of the 4rd draft according to Remi's comments. We are very
thanking Remi to provide his valuable comments.
Thanks,
Tetsuya Murakami
Begin forwarded message:
差出人: internet-dra...@ietf.org
件名: I-D Action: draft-murakami-softwire-4rd-01.txt
日時: 2011年9月24日 16:20:54 GMT
good to have Ole and Woj suggested agenda. But I'd
like to know what their reasoning for the original agenda. Could you share it
with us?
+1
The agenda posted by Woj looks good.
Thanks,
Tetsuya Murakami
--satoru
cheers,
Ole
1. Intro, logistics, chairs
2. Stateless IPv4 address
, implementation, etc.
Thanks,
Tetsuya Murakami
On 2011/09/06, at 22:35, mohamed.boucad...@orange-ftgroup.com
mohamed.boucad...@orange-ftgroup.com wrote:
Dear Gang,
As per the following property:
o Complexity: Complexity level of the algorithm
I agree this can be split into several sub
Hi Chairs,
We would like to have a presentation for draft-murakami-softwire-4rd-00 in the
interim meeting in order to discuss about the stateless solution. Please assign
a slot for this.
Thanks,
Tetsuya Murakami
On 2011/08/22, at 8:37, Alain Durand wrote:
As we mentioned earlier
for people, I recommend you to collaborate with your friend.
+1
Agreed. We need to discuss about this more.
Thanks,
Tetsuya Murakami
cheers,
--satoru
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
Sorry. I have a typo. The following address has no meaning...
Sorry again.
Tetsuya Murakami
On 2011/08/16, at 21:16, Tetsuya Murakami wrote:
Hi Remi, Jacni,
We are considering the following situation.
Initially, one 4rd mapping rule can be set like {2408:db8::/32, 10.10.0.0/24,
48
with the the destination
ipv4 address, can be selected.
It is stated in section 5.1.1 and section 7 a little bit in the draft.
Thanks,
Tetsuya Murakami
On 2011/08/14, at 5:52, Washam Fan wrote:
Hi,
It seems to me only one domain IPv6 prefix is allowed, per
draft-murakami-softwire-4rd-00. But I see no issue
platform in your test ?
Did you asked about the forwarding performance? We used netbsd running on arm
core cpu (400MHz). The accrual ratio of the latency is just 2 to 5 % under 4rd
environment.
Thanks,
Tetsuya Murakami
At the same time as other parameters (once in awhile to avoid lifetime
Hi Simon,
On 2011/08/04, at 5:26, Simon Perreault wrote:
On 2011-08-03 16:44, Tetsuya Murakami wrote:
So the 900G figure is valid *in theory*, but *in practice* we're
stuck with a number of sessions roughly equal to the number of
external ports available on the NAT.
As I mentioned above
Hi Remi, Qiong,
- For this each CE must know mapping rules for all other CE's.
[Qiong]: Agree, especially when applying the co-existence scenario for
exclusive-mode and shared mode. Given the fact the IPv4 prefixes are not
continuous anymore, there might be up to hundreds/thousands of
. If these condition of IPv6 source and
destination address is not matched, 4via6 CE can process the received IPv6
packets as the normal IPv6 packet. So, I don't think there is no issue which
you raised.
Thanks,
Tetsuya Murakami
On 2011/07/19, at 9:53, GangChen wrote:
Hello Remi,
I guess 4V6 CE need
Hi,
+1.
One motivation draft should be fine.
On 2011/05/24, at 1:23, Ole Troan wrote:
Having said that I saw
draft-operators-softwire-stateless-4v6-motivation-01
which covers very similar scenarios.
I suggest the authors work together and possibly merge their documents.
+1.
I
to be changed.
Thanks,
Tetsuya Murakami
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
CPE box, the application can use
this private IPv4 address.
Thanks,
Tetsuya Murakami
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
33 matches
Mail list logo
