. The full /128 prefix is then constructed in the same manner as
[I-D.ietf-softwire-map].
---
- Original Message -
From: Ole Troan
Sent: 03/06/14 04:34 PM
To: Ian Farrer
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt
Ian, OK, so what about the following text? yes
: Thursday, March 6, 2014 at 6:27 PM
To: Yiu L. LEE yiu_...@cable.comcast.com
Cc: Softwires-wg WG softwires@ietf.org
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt
On 6 March 2014 15:41, Lee, Yiu yiu_...@cable.comcast.com wrote:
I still have problem to include text
On 07/03/2014 3:04 AM, Wojciech Dec wrote:
On 6 March 2014 21:06, Lee, Yiu yiu_...@cable.comcast.com wrote:
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
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
: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt
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
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
note that MAP-E would get also a suitable pointer to the lw46 draft
concerning the 1:1 mode.
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: Re: [Softwires] I-D Action: draft
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
...@gmail.com
Date: Thursday, March 6, 2014 at 6:27 PM
To: Yiu L. LEE yiu_...@cable.comcast.com
Cc: Softwires-wg WG softwires@ietf.org
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt
On 6 March 2014 15:41, Lee, Yiu yiu_...@cable.comcast.com wrote:
I still have
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
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
HI Woj / Simon,
Below is some proposed text around interface and prefix selection for tunnel
creation.
@Simon, this changes some of the text that we previously agreed at WGLC, so
please can you check it over?
Cheers,
Ian
Well, so the text from the above discussion does not appear in the
Le 2014-03-05 14:29, Ian Farrer a écrit :
If the longest prefix match returns more than one matching prefix, then an
implementation specific tie-breaker MUST be performed to return a single
prefix.
Does this mean that the lwB4 and lwAFTR would need to be from the same
vendor?
Simon
--
DTN
No. As long as you know what particular mechanism you B4 vendor has
implemented, you can provision accordingly.
The lwAFTR never has to do the LPM. It’s just got a tunnel endpoint address
configured by the operator.
Cheers,
Ian
On 5 Mar 2014, at 14:34, Simon Perreault
Fine then.
Simon
Le 2014-03-05 14:38, Ian Farrer a écrit :
No. As long as you know what particular mechanism you B4 vendor has
implemented, you can provision accordingly.
The lwAFTR never has to do the LPM. It’s just got a tunnel endpoint address
configured by the operator.
Cheers,
Ian,
No. As long as you know what particular mechanism you B4 vendor has
implemented, you can provision accordingly.
The lwAFTR never has to do the LPM. It’s just got a tunnel endpoint address
configured by the operator.
I'm not comfortable with that.
is there any reason why you
AM
To: Yiu L. LEE yiu_...@cable.comcast.com
Cc: Softwires-wg softwires@ietf.org
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt
On 3 March 2014 17:57, Lee, Yiu yiu_...@cable.comcast.com wrote:
How MAP-E aggregates CPE for N CEs in hub-and-spoke? When implementing MAP
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.
Best Regards,
Qi
On 2014-3-3, at 下午1:47, Wojciech Dec wrote:
Current
Hi Ted,
my comment refers specifically to the characterization of MAP in the
introduction of the lw46 draft. I keep on restating this, because this
characterization of MAP is not correct - the current text states ..If this
type of meshed interconnectivity is required,
...@telekom.de, Softwires-wg
softwires@ietf.org
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt
It done by having 1 rule for N CEs, i.e. route aggregation vs host routes
On 3 March 2014 15:19, Lee, Yiu yiu_...@cable.comcast.com wrote:
Sorry for my ignorance. How MAP-E
If, as you say, Ian is happy to make the change that you've proposed, then I
have no problem with that. However, let's not needlessly delay both of these
drafts arguing about marketing boilerplate. The text as written is not a
sufficiently glowing recommendation of MAP, but it doesn't need
If, as you say, Ian is happy to make the change that you've proposed, then I
have no problem with that. However, let's not needlessly delay both of
these drafts arguing about marketing boilerplate. The text as written is
not a sufficiently glowing recommendation of MAP, but it doesn't
This could certainly save a spending the rest of the week micro-editing
wording, so I’d be happy with it.
An extremely tentative further suggestion:
Should there be a draft which discusses the available softwire solutions more
throughly (we would tackle this only after we’ve got the WGCLs
Sorry, but I'll insist for a number of reasons:
1. It is technically valid
2. The solutions are clearly closely related. Not stating that in any way
would be ridiculous.
3. It presents (introduces) the context of the draft, and as I said MAP-E
should do likewise. It is not a detailed pro/con.
4.
On Mar 4, 2014, at 9:42 AM, Ole Troan otr...@employees.org wrote:
I have had success in the past by removing contentious text. I think that
could work here, just remove this paragraph:
WFM, but the authors have to agree. :)
___
Softwires mailing
On Mar 4, 2014, at 9:54 AM, Ian Farrer ianfar...@gmx.com wrote:
Should there be a draft which discusses the available softwire solutions more
throughly (we would tackle this only after we’ve got the WGCLs completed, so
there’s something to actually compare)?
A basket of vipers, I’m sure,
On Mar 4, 2014, at 10:04 AM, Wojciech Dec wdec.i...@gmail.com wrote:
Sorry, but I'll insist for a number of reasons:
Woj, can we please not speak in terms of insisting? You are a working group
participant. If you have a technical issue _which would prevent the standard
from functioning_
I was speaking as a WG participant, and I was referring to my proposal made
in that capacity. Furthermore, there is nothing factually wrong with what I
said, nor you appear to question that. The text that you oddly claim will
take years to resolve, took 5 mins to agree with Ian (yesterday).
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt
Hi Woj / Senthil,
Putting the other discussions to the side for a moment, can we tackle
the fragmentation text you proposed as this should be easily resolvable?
Suggested text:
The NAT44 in the lwB4 MUST implement
On Mar 4, 2014, at 10:26 AM, Wojciech Dec wdec.i...@gmail.com wrote:
I was speaking as a WG participant, and I was referring to my proposal made
in that capacity. Furthermore, there is nothing factually wrong with what I
said, nor you appear to question that. The text that you oddly claim
Hi Ian,
On 03/04/2014 04:54 AM, Ian Farrer wrote:
This could certainly save a spending the rest of the week micro-editing
wording, so I’d be happy with it.
An extremely tentative further suggestion:
Should there be a draft which discusses the available softwire solutions more
throughly (we
This could certainly save a spending the rest of the week micro-editing
wording, so I’d be happy with it.
An extremely tentative further suggestion:
Should there be a draft which discusses the available softwire solutions
more throughly (we would tackle this only after we’ve got the
OK, it was merely a suggestion….
I’m mildly relieved I don’t have to write it.
Ian
On 4 Mar 2014, at 14:27, Ole Troan otr...@employees.org wrote:
This could certainly save a spending the rest of the week micro-editing
wording, so I’d be happy with it.
An extremely tentative further
On 04/03/2014 9:47 AM, Suresh Krishnan wrote:
Hi Ian,
On 03/04/2014 04:54 AM, Ian Farrer wrote:
This could certainly save a spending the rest of the week
micro-editing wording, so I’d be happy with it.
An extremely tentative further suggestion:
Should there be a draft which discusses the
Hi Suresh,
On 26 February 2014 02:10, Suresh Krishnan suresh.krish...@ericsson.comwrote:
Hi Woj,
On 02/25/2014 05:12 AM, Wojciech Dec wrote:
Hi Qi,
your answers didn't answer the majority of the concerns raised. And some
of those raised by Ole still also stand:
- Clean-up text that
On 3 March 2014 14:54, Ted Lemon ted.le...@nominum.com wrote:
On Mar 3, 2014, at 1:47 PM, Wojciech Dec wdec.i...@gmail.com wrote:
Lightweight 4over6 provides a solution for a hub-and-spoke softwire
architecture only,
where the AFTR maintains (softwire) state for each subscriber. A means
From: Wojciech Dec wdec.i...@gmail.com
Date: Wednesday, 19 February 2014 09:34
To: Ian Farrer ianfar...@gmx.com
Cc: Softwires-wg softwires@ietf.org
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt
Hi Ian,
Just to be clear: I'm ok with lw46 defining a specific
3, 2014 at 1:47 PM
To: ian.far...@telekom.de ian.far...@telekom.de
Cc: Softwires-wg softwires@ietf.org
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt
Hi Ian,
following up with some proposed text re relation to MAP
On 26 February 2014 10:31, ian.far...@telekom.de
To: ian.far...@telekom.de ian.far...@telekom.de
Cc: Softwires-wg softwires@ietf.org
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt
Hi Ian,
following up with some proposed text re relation to MAP
On 26 February 2014 10:31, ian.far...@telekom.de wrote:
Hi Woj,
I've been
: Wojciech Dec wdec.i...@gmail.com
Date: Wednesday, 19 February 2014 09:34
To: Ian Farrer ianfar...@gmx.com
Cc: Softwires-wg softwires@ietf.org
Subject: Re: [Softwires] I-D Action:
draft-ietf-softwire-lw4over6-06.txt
Hi Ian,
Just to be clear: I'm ok with lw46 defining a specific functional mode
: Wojciech Dec wdec.i...@gmail.com
Date: Wednesday, 19 February 2014 09:34
To: Ian Farrer ianfar...@gmx.com
Cc: Softwires-wg softwires@ietf.org
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt
Hi Ian,
Just to be clear: I'm ok with lw46 defining a specific functional
: Wojciech Dec wdec.i...@gmail.com
Date: Monday, March 3, 2014 at 1:47 PM
To: ian.far...@telekom.de ian.far...@telekom.de
Cc: Softwires-wg softwires@ietf.org
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt
Hi Ian,
following up with some proposed text re relation to MAP
...@gmail.com
Date: Wednesday, 19 February 2014 09:34
To: Ian Farrer ianfar...@gmx.com
Cc: Softwires-wg softwires@ietf.org
Subject: Re: [Softwires] I-D Action:
draft-ietf-softwire-lw4over6-06.txt
Hi Ian,
Just to be clear: I'm ok with lw46 defining a specific functional mode
as I believe
?
From: Wojciech Dec wdec.i...@gmail.com
Date: Monday, March 3, 2014 at 1:47 PM
To: ian.far...@telekom.de ian.far...@telekom.de
Cc: Softwires-wg softwires@ietf.org
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt
Hi Ian,
following up with some proposed text re
Date: Monday, March 3, 2014 at 1:47 PM
To: ian.far...@telekom.de ian.far...@telekom.de
Cc: Softwires-wg softwires@ietf.org
Subject: Re: [Softwires] I-D Action:
draft-ietf-softwire-lw4over6-06.txt
Hi Ian,
following up with some proposed text re relation to MAP
On 26 February 2014 10:31
On Mar 3, 2014, at 2:10 PM, Wojciech Dec wdec.i...@gmail.com wrote:
From a previous mail (that you perhaps missed):
I didn't miss it. The distinction you are making is finally making sense to
me after many repetitions. Sorry for being dense.
I think what you are trying to avoid is the
Le 2014-03-03 14:52, Wojciech Dec a écrit :
Lightweight 4over6 provides a solution for a hub-and-spoke softwire
architecture only,
where the AFTR maintains (softwire) state for each subscriber. A means for
optmizing the amount of such state using IPv4-IPv6 address mapping rules, as
well
: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt
Le 2014-03-03 14:52, Wojciech Dec a écrit :
Lightweight 4over6 provides a solution for a hub-and-spoke softwire
architecture only, where the AFTR maintains (softwire) state for each
subscriber. A means for optmizing the amount
...@telekom.de, Softwires-wg
softwires@ietf.orgmailto:softwires@ietf.org
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt
Hi Woj / Senthil,
Putting the other discussions to the side for a moment, can we tackle the
fragmentation text you proposed as this should be easily
:54 PM
To: Wojciech Dec wdec.i...@gmail.com, Senthil Sivakumar ssent...@cisco.com
Cc: ian.far...@telekom.de ian.far...@telekom.de, Softwires-wg
softwires@ietf.org
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt
Hi Woj / Senthil,
Putting the other discussions
On Mar 3, 2014, at 4:46 PM, Simon Perreault simon.perrea...@viagenie.ca wrote:
(This is not wordsmithing since I'm proposing a figure. It's
figure-smithing.)
Which document would have to have this figure in it? :)
___
Softwires mailing list
On Mar 3, 2014, at 7:47 PM, Simon Perreault simon.perrea...@viagenie.ca wrote:
Ah, I don't know, maybe the working group charter? :-)
(Was semi-joking, am fully joking now.)
If putting it in the charter gets these documents through last call, you have
your AD's support. Well, okay, maybe
: Softwires-wg softwires@ietf.orgmailto:softwires@ietf.org
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt
Hi Ian,
Just to be clear: I'm ok with lw46 defining a specific functional mode as I
believe it does in this draft, also leaving as-is the DHCP part of it (i.e.
it's
Ted,
May I kindly ask that you read my comments before starting apparently
rhetorical discussions of the type that I didn't intend, and that do not
progress things?
In summary: I said that having a lw46 draft/solution is fine, but it is
clear that there is significant technical overlap between
Farrer ianfar...@gmx.com
Cc: Softwires-wg softwires@ietf.org
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt
Hi Ian,
Just to be clear: I'm ok with lw46 defining a specific functional mode as
I believe it does in this draft, also leaving as-is the DHCP part of it
(i.e
On Feb 25, 2014, at 5:12 AM, Wojciech Dec wdec.i...@gmail.com wrote:
I still see no reason why they cannot be addressed by edits to the draft that
don't change the matter that lw46 is a standalone draft.
Woj, please propose text if you want changes.
I think you're being unfair on one point. 1:1 mode was an afterthought
in MAP, appearing after LW4o6 had been published. It is not reasonable
to say now that LW4o6 is just a subset of MAP because 1:1 mode is
possible in the latter. 1:1 is certainly not MAP's main thrust.
I know this is a
I know this is a political rather than a technical point, but one could sort
of reverse the claim and suggest that if 1:1 mode is desired, LW4o6 is the
better way to go.
Indeed, if all one needs is 1:1, one might prefer lw4over6 since it only has
the one mode.
I think the point he was
On Feb 25, 2014, at 6:11 PM, Ole Troan otr...@employees.org wrote:
I think the point he was trying to make was that it isn't optimal to have two
standards documents, specifying mechanisms where one is almost completely
encompassed by the other. I say almost, because there might be some
On 25 Feb 2014, at 23:55 , Ted Lemon ted.le...@nominum.com wrote:
On Feb 25, 2014, at 6:11 PM, Ole Troan otr...@employees.org wrote:
I think the point he was trying to make was that it isn't optimal to have
two standards documents, specifying mechanisms where one is almost
completely
Hi Qi,
afraid that your answers didn't answer the majority of the concerns raised.
I still see no reason why they cannot be addressed by edits to the draft
that don't change the matter that lw46 is a standalone draft.
Inline...
On 21 February 2014 10:25, Qi Sun sunqi.csnet@gmail.com
Hi Woj,
On 02/25/2014 05:12 AM, Wojciech Dec wrote:
Hi Qi,
your answers didn't answer the majority of the concerns raised. And some
of those raised by Ole still also stand:
- Clean-up text that does not belong to lw46 (eg 2473 fixes, NAT44 best
practice).
- Clarification of WAN selection or
Hi Woj,
On 2014-2-19, at 下午4:34, Wojciech Dec wrote:
Just to be clear: I'm ok with lw46 defining a specific functional mode as I
believe it does in this draft,
[Qi] The outcome of ietf88 was lw4o6 and map are two mechanisms, but both use
the Softwire DHCP for provisioning (at least
Hi Ian,
Just to be clear: I'm ok with lw46 defining a specific functional mode as I
believe it does in this draft, also leaving as-is the DHCP part of it
(i.e. it's a capability that can be signalled using the lw46 container,
etc).
General items remain open (as commented):
- Cleanup text that
Hi Woj,
Please see inline.
Cheers,
Ian
On 16 Feb 2014, at 17:32, Wojciech Dec wdec.i...@gmail.com wrote:
Hi Ian,
you haven't replied on my high level comment - would appreciate if you
introduced changes to that effect in the draft.
Continued inline…
[ian] The draft already contains
Hi Ian,
you haven't replied on my high level comment - would appreciate if you
introduced changes to that effect in the draft.
Continued inline...
On 14 February 2014 20:24, ian.far...@telekom.de wrote:
Hi Woj,
Thanks for the review. Inline are some comments specifically related to
your
Hi Ole,
Thanks for the review. Please see inline.
Cheers,
Ian
On 11/02/2014 11:28, Ole Troan otr...@employees.org wrote:
a few initial comments:
s/connectivity services/connectivity/
s/OPTION_SW46_LW/OPTION_S46_CONT_LW/
[ian] OK
section 5.1
An IPv6 address from an assigned prefix is
Hi Ian, All,
I read the latest draft and have a number of comments.
High level:
Based on my understanding the lwB4 architecture now has the following
ingredients:
- The PSID and the port range are algorithmically derived related as per
the MAP algorithm (covered in Section 5.1)
- The assigned
Hi Woj,
Thanks for the review. Inline are some comments specifically related to your
points on the new text that's been added since WGLC.
Cheers,
Ian
Detailed comments:
* Section 5.1 WAN prefix selection and address forming - as per Ole's comment.
This is indeed hand wavy in the current
80 matches
Mail list logo
