Hi,
IMO The MAP solution fullfills most, if not all of the points in the
stateless motivations draft. The fact that it can do more, or can be used
differently doesn't alter the solution.
Now, it would appear that you're arbitrarily trying to make sure that MAP
does not solve a problem you care
+1 support.
I respect what the MAP authors have worked on. But besides what Peng has
said, could you clarify where the so called ietf-map-00 achieves
consensus?
Qi Sun
On Tue, Jun 26, 2012 at 12:07 PM, Peng Wu pengwu@gmail.com wrote:
Woj,
On Mon, Jun 25, 2012 at 10:24 PM, Wojciech Dec
Hi, Peng,
I totally agree with you.
AFAIK, the originally MAP draft is designed to solve the stateless scenarios in
a IPv4 info embedded way. Now one day, the 1:1 mode was suddenly added by
setting the EA bits to zero without any consent from the WG, which also
abandoned the essence of
Hi Satoru,
Comment in line below.
Best regards,
Ian
Date: Mon, 25 Jun 2012 18:46:18 +0900
From: Satoru Matsushima
satoru.matsush...@gmail.commailto:satoru.matsush...@gmail.com
To: Peng Wu pengwu@gmail.commailto:pengwu@gmail.com
Cc: softwires@ietf.orgmailto:softwires@ietf.org, Yong Cui
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
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:
2012-06-25 à 16:24, Wojciech Dec:
...
The updated MAP draft does not change the MAP architecture nor
On 26 June 2012 09:13, ian.far...@telekom.de wrote:
Hi Satoru,
Comment in line below.
Best regards,
Ian
Date: Mon, 25 Jun 2012 18:46:18 +0900
From: Satoru Matsushima satoru.matsush...@gmail.com
To: Peng Wu pengwu@gmail.com
Cc: softwires@ietf.org, Yong Cui cuiy...@tsinghua.edu.cn
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
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 Després despres.r...@laposte.net wrote:
Hi,
comments:
section 4.2 of the draft reads:
a MAP domain is a set of MAP CEs and BRs connected to the same virtual
link. One MAP domain shares a common BR and has the same set of BMRs, FMRs
and DMR, and it can be further divided into multiple sub-domains when
multiple IPv4 subnets are
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
Satoru - Let's think that a CE provisioned with following BMR comes from MAP
DHCPv6 options.
BMR:
o Rule-ipv6-prefix : {exact matched with CE's delegated prefix}
o Rule-ipv4-prefix : x.x.x.x/32
o EA-length : 0
o Port-param option : {PSID/length}
This BMR could be a LW46
Hi All,
I see few points of this draft need to be addressed to address
complete solution.
1). Section 6.2 mentions the mB4 must drop non-matching (mPrefix64 and
uPrefix64) packets silently. There can be scenarios, where some of LAN
Multicast receivers are supporting native IPv6. How will
Hi Shailesh,
Thanks very much of reviewing the draft. Please read comments inline:
On 6/26/12 8:07 AM, Shailesh Suman sumanshail...@gmail.com wrote:
Hi All,
I see few points of this draft need to be addressed to address
complete solution.
1). Section 6.2 mentions the mB4 must drop
On 2012-06-26 04:50, Wojciech Dec wrote:
- A parameter PER DOMAIN was an obvious result of a merger.
- But a parameter PER RULE is a significant novelty.
OK?
That was not intended, and appears to be a genuine mistake in draft-00.
Thanks for spotting.
It is a parameter per domain, as
Agree with Ian.
MAP is designed and optimized for algorithmatic address mapping, but not
for per-subscriber rule mapping. Actually, the more you would like to
solve, more complicated it will become.
I will certainly not buy MAP for per-subscriber case when MAP-T, MAP-E,
map-dhcp all becomes
On 2012/06/27, at 0:11, Qiong wrote:
Agree with Ian.
MAP is designed and optimized for algorithmatic address mapping, but not for
per-subscriber rule mapping. Actually, the more you would like to solve, more
complicated it will become.
I will certainly not buy MAP for per-subscriber
dear Satoru,
2012/6/26 Satoru Matsushima satoru.matsush...@gmail.com
On 2012/06/27, at 0:11, Qiong wrote:
Agree with Ian.
MAP is designed and optimized for algorithmatic address mapping, but not
for per-subscriber rule mapping. Actually, the more you would like to
solve, more
+1 for draft-ietf-softwire-map-00
Best Regards,
Leaf
-Original Message-
From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf
Of Simon Perreault
Sent: Tuesday, June 26, 2012 9:58 PM
To: softwires@ietf.org
Subject: [Softwires] MAP design team [Was: Re:
Hi Maoke,
On 2012/06/27, at 10:48, Maoke wrote:
dear Satoru,
2012/6/26 Satoru Matsushima satoru.matsush...@gmail.com
On 2012/06/27, at 0:11, Qiong wrote:
Agree with Ian.
MAP is designed and optimized for algorithmatic address mapping, but not
for per-subscriber rule mapping.
hi dear authors,
as the map-00 draft contains the normative 1:1 mode statement that is new
in comparison to the previous versions, i'd like to ask some technical
questions in order to clarify the understanding.
Section 4. page 9:
MAP can also be provisioned in 1:1 mode. In 1:1 mode the BR has a
On Wed, Jun 27, 2012 at 10:20 AM, Satoru Matsushima
satoru.matsush...@gmail.com wrote:
Hi Maoke,
On 2012/06/27, at 10:48, Maoke wrote:
dear Satoru,
2012/6/26 Satoru Matsushima satoru.matsush...@gmail.com
On 2012/06/27, at 0:11, Qiong wrote:
Agree with Ian.
MAP is designed and
2012/6/26 Wojciech Dec wdec.i...@gmail.com
Hi,
comments:
section 4.2 of the draft reads:
a MAP domain is a set of MAP CEs and BRs connected to the same virtual
link. One MAP domain shares a common BR and has the same set of BMRs, FMRs
and DMR, and it can be further divided into multiple
I might have a naive question: why does the Softtwire-WG need a document for
deployment other than a document for motivation?
I guess the answer might be the motivation is for the requirements, and the
deployment is for the specified application cases, right? But to me the answer
might be as
On 2012/06/27, at 12:36, Peng Wu wrote:
Not quite.
I believe that the most motivate to start this work in the wg has destined
MAP to be 'multi-protocol socket v2.0' that's what the former wg chair
wished to. Do you remember that?
i like the philosophy of multi-protocol socket. however, i
Hi Leaf,
On Wed, Jun 27, 2012 at 12:18 PM, Leaf yeh leaf.y@huawei.com wrote:
I might have a naive question: why does the Softtwire-WG need a document
for deployment other than a document for motivation?
Qiong: We already have a motivation draft that clearly demenstrates the
requirements.
26 matches
Mail list logo
