Dear all,
Sorry I don't agree the following changes Woj proposed, same reason as Ted
mentioned below.
Thank you,
Tina
On Mar 3, 2014, at 5:55 AM, Ted Lemon
ted.le...@nominum.commailto:ted.le...@nominum.com wrote:
On Mar 3, 2014, at 1:47 PM, Wojciech Dec
Qi,
On 5 March 2014 17:17, Qi Sun sunqi.csnet@gmail.com wrote:
Woj,
I don't think map is more optimized than lw4over6 when IPv4 and IPv6 are
totally decoupled (which is lw4over6 designed to deal with). I would prefer
to follow Ole's suggestion at this point, i.e. remove this text.
Here’s the text that Woj mentioned:
Lightweight 4over6 provides a solution for a hub-and-spoke softwire
architecture only, where the lwAFTR maintains (softwire) state for each
subscriber. [I-D.ietf-softwire-map] offers a means for optimizing the amount of
such state by using algorithmic IPv4
Yuchi,
IMHO doing LPM with the lwAFTR's address is more straightforward than with a
Domain v6 prefix.
In addition, I don't see why Ian's proposal cannot cover the case you
mentioned, the case in which an address out of the prefix domain can be
chosen as the tunnel endpoint address. If
On 06/03/2014 8:10 AM, Ole Troan wrote:
Yuchi,
IMHO doing LPM with the lwAFTR's address is more straightforward than with a Domain
v6 prefix.
In addition, I don't see why Ian's proposal cannot cover the case you
mentioned, the case in which an address out of the prefix domain can be chosen
It really depends on what you mean by 'the wheel' in this context…
But, as a proposal, if we extend (and maybe rename) OPTION_L46_IPV4ADDRESS with
new fields for prefix6-len and ipv6-prefixes to be used for a LPM, would this
meet your definition of a wheel?
Cheers,
Ian
On 5 Mar 2014, at
Tom,
I'm a bit surprised to still see the expression Unified CPE. I thought we
had determined during DHCP discussions that MAP-E and LW4o6 are too different
to unify very much.
what are you saying?
that even when there is common functions, we should actively make them
different?
(yes, I'm
Ian,
It really depends on what you mean by 'the wheel' in this context…
But, as a proposal, if we extend (and maybe rename) OPTION_L46_IPV4ADDRESS
with new fields for prefix6-len and ipv6-prefixes to be used for a LPM, would
this meet your definition of a wheel?
pretty much. my point was
I still have problem to include text to compare two methods. Why not remove
the whole sentence as Ole stated in his email?
Yiu
From: Ian Farrer ianfar...@gmx.com
Date: Thursday, March 6, 2014 at 11:27 AM
To: Wojciech Dec wdec.i...@gmail.com
Cc: Softwires-wg WG softwires@ietf.org
Subject:
Ole,
A clarification question. Do you suggest to use S46 Rule Option?
Thanks,
Yiu
On 3/6/14, 1:37 PM, Ole Troan otr...@employees.org wrote:
Ian,
It really depends on what you mean by 'the wheel' in this context
But, as a proposal, if we extend (and maybe rename)
OPTION_L46_IPV4ADDRESS
Hi,
As a document for standards track, I don't think lw4over6 should include this
text to compare between lw4over6 and map, nor the so-called pointer text
there.
I recommend we remove this text from the lw4over6 draft.
Best Regards,
Qi
On 2014-3-6, at 上午11:27, Ian Farrer wrote:
Here’s
Hi all,
I have to agree with Qi. It is hard to define which one is an _optimized_
solution clearly than another one. Different operators would have different
situations and there is always tradeoff among different solutions.
I think we do not need to compare with map in lw4o6 draft, but just to
Hi Ole,
I agree that we should choose the better algorithm. Provisioning a prefix seems
can introduce more flexibility.
I don't agree that we should try to unify lwB4 and MAP-E CE.
Regards,
--
Yuchi
On 2014-03-06, 21:10, Ole Troan otr...@employees.org wrote:
Yuchi,
IMHO doing
Ian,
OK, so what about the following text?
yes, that seems along the right lines.
you may want to create some indirection between the main protocol specification
and the DHCP provisioning document, like we talked about (and did for MAP) back
in Berlin.
cheers,
Ole
For DHCPv6 based
On 6 March 2014 15:41, Lee, Yiu yiu_...@cable.comcast.com wrote:
I still have problem to include text to compare two methods. Why not
remove the whole sentence as Ole stated in his email?
You appear not to have had a problem with the current text. What is the
problem with the new one?
Also
Would you be more comfortable with reducing?
On 6 March 2014 16:17, Yuchi Chen cheny...@gmail.com wrote:
Hi Ian,
If we decided to keep the text, I suggest to remove the offers a means
for optimizing part. It may not be a good idea to teach operators what
should be optimize.
What I mostly
In the current text, there is no comparison term such as “more optimizing”
or “reducing”. These terms are used to comparing two solutions. I echo Qiong
and Qi in their replies: this is not necessary to compare two solutions.
Similarly, I also think it is not necessary to mention lw4o6 in the MAP-E
When in doubt, take it out.
I'll propose methodology for another draft comparing the various
approaches in a separate E-mail message.
On 06/03/2014 1:27 PM, Wojciech Dec wrote:
On 6 March 2014 15:41, Lee, Yiu yiu_...@cable.comcast.com wrote:
I still have problem to include text to compare
Comments and additions are invited. If there is no enthusiasm for the
project I'll drop the subject.
Scope
-
This would cover the various Softwires 4 across 6 approaches: DS-Lite
(with GI DS-Lite a special case), MAP-E, LW4o6, MAP-T, 4rd.
Method
--
In summary, the analysis would
Hi Tom,
I also prefer to compare with these solutions in a separate draft.
Best wishes
Qiong
On Fri, Mar 7, 2014 at 4:09 AM, Tom Taylor tom.taylor.s...@gmail.comwrote:
When in doubt, take it out.
I'll propose methodology for another draft comparing the various
approaches in a separate
20 matches
Mail list logo
