Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt

From: Wojciech Dec <[email-masked]>
Date: Mon, 3 Mar 2014 14:31:12 +0100

Hi Suresh,

On 26 February 2014 02:10, Suresh Krishnan <[email-masked]>wrote:

> 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 assumptions
>> - Clarify questionable use of ICMPv6 error code (to report lack of v4
>> binding)
>>
>> 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.
>>
>
> In all fairness, your comments came in a few hours before the draft
> submission deadline for this IETF. It is unreasonable to expect the issues
> to get addressed by draft changes, at least until the submission reopens. I
> do think the above points merit a response from the document editors.

Thanks.

>
>
> > - Text clarifying relation to MAP-E (both use MAP PSID algo, address
> > embedding, IPv4inIPv6 and NAT44 w/ address sharing. MAP allows state to
> > be ranged from N to 1 per CPE. lw46 focuses on the 1:1 case)
>
> Why do you think this is required here? Isn't this the goal of the unified
> CPE work (to clarify the commonalities between MAP and lw4over6)?
>

There is a difference: Here I'm pointing out that IPinIP dataplane + ICMP
wise there should be no difference between lw46 and MAP-E, and in effect a
MAP BR or lw46 AFTR implementation of these would be no different. There is
no talk of provisioning.
uCPE attempts to bring in all mechanisms, also beyond -E and lw46, + their
various provisioning options for a single CPE.

Cheers,
Wojciech.

>
> Thanks
> Suresh
>
>
>>
>> Snipped text Inline... Woj>
>>
>>
>> On 21 February 2014 10:25, Qi Sun <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>
>>     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 according to
>>     my memory). That is why the WG decided to remove the statement of
>>     "lw4o6 is a subset of MAP-E" is from the Softwire DHCP Option draft.
>>
>>     And lw4o6 can use DHCPv4 over DHCPv6 and PCP for provisioning. This
>>     is documented in the current lw4o6 draft, and some teams are doing
>>     the documentation work. (We have demoed in IETF85 that lw4o6 can
>>     work with DHCPv4 over IPv6 and PCP). The point is, lw4o6
>>     architecture is quite flexible.
>>
>>
>>
>> Woj>I didn't quite comment on the DHCP draft, nor on how flexible and
>> clear *you think* the lw46 draft is, etc. I commented on the fact that
>> that lw46 shares a lot with MAP-E and the fact that it is built on the
>> same technology blocks as MAP-E, but realizes solely the 1:1 part should
>> be clarified.
>>
>> Irrespective of this, there is overall no reason for having text in the
>> lw46 draft that fixes 2473 or NAT44 best practices, etc.
>>
>>
>>      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 does not belong to lw46 (eg 2473 fixes, or
>>>     NAT44 best practice).
>>>
>>
>>     [Qi] IMO, that text guarantees the interoperation between lwAFTRs
>>     and lwB4s from different vendors, which bothered us a little when
>>     carrying out the interop test. I think it doesn't hurt to make it
>>     specific.
>>
>>
>> Woj>A couple of points:  Firstly: Given that the lwB4 CPE uses the MAP
>> algorithm for the PSID and embeds the IPv4+PSID in its IPv6 address, the
>> text is now in shape that a lwB4 would be interoperable with a MAP-E BR.
>> This is actually good convergence/progress. What remains open in that
>> happening is actually weeding out the possible source of differences,
>> which appear to be in the nuances of ICMP handling.
>>
>> Secondly: It claims to be a standards track document (currently), and it
>> carries text that selectively duplicates text in other standard rfcs
>> without deferring to those RFCs. If there are any reasons why this
>> "cherry picking" was made, while other recommendations (say re NAT44)
>> were not adopted, they should be clarified. In general for rfc2473,
>> there I see so far no zero reason to have some other text here, as
>> opposed to errata. Same for NAT44 really.
>>
>> Then again, perhaps the draft should be interpreted as an RFP of some
>> kind, which it actually reads a lot like. In which case it should not be
>> a standard track document.
>>
>>
>>      - Clarification of WAN selection or assumptions
>>>
>>
>>     [Qi] I think Ian has expressed cleared in previous mails.
>>
>>
>>
>> Woj>Please see my reply to Ian - looking forward to an answer in the
>> draft:
>> --snip--
>> So, in terms of the lw46 draft specifying how a CPE is to get to the IP
>> prefix of  "the WAN interface" is an important aspect, or at least
>> stating the assumptions about this WAN interface. Some obvious questions
>> apply here:
>> is the WAN the interface which has the default route? Is it the
>> interface that has a DHCPv6 client? What if there are multiple such
>> "WAN" interfaces? What if a single "WAN" has multiple IPv6 prefixes?
>> What if it has NO global IPv6 prefix? What if it doesn't have a /64
>> prefix. etc.
>> --snip--
>> One doesn't see the draft answering any of these at the moment.
>>
>>
>>
>>>     That said, abundant technical evidence (summarized in previous
>>>     mail) indicates that this mode is in near total overlap with MAP
>>>     1:1, certainly much more than at the outset of this work. Given
>>>     this, why not align the text and actually make MAP 1:1 and lw46 be
>>>     the same? On all of the data plane IPv6, IPv4, NAT44, tunneling
>>>     and ICMP handling parts I see there no reason for there being a
>>>     difference...
>>>
>>
>>     [Qi] I think lw4o6 is clean and simple, and flexible to work with
>>     different provisioning mechanisms (signaling through the Softwire
>>     DHCP as is agreed by the WG).
>>
>>
>>
>>>     continued inline...
>>>
>>>
>>>
>>>
>>>         [ian] The draft already contains the following text (and has
>>>         for some time):
>>>
>>>             Lightweight 4over6 provides a solution for a hub-and-spoke
>>> softwire
>>>             architecture only.  It does not offer direct, meshed IPv4
>>>             connectivity between subscribers without packets traversing
>>> the AFTR.
>>>             If this type of meshed interconnectivity is required,
>>>             [I-D.ietf-softwire-map] provides a suitable solution.
>>>
>>>         So, are you not happy with the wording of the current
>>>         reference, or are you requesting that the draft is rewritten
>>>         to be cast as a ‘specialised' case of MAP?
>>>
>>>     What I pointed out is that the Lw46 draft has major if near total
>>>     overlap with MAP-E 1:1 mode. Stating that lw46 realizes this mode,
>>>     in a standalone way from the N:1 mesh mode, is what I propose.
>>>     This would greatly help in implementing it and "digesting" the
>>>     array of solutions.
>>>
>>
>>     [Qi] I don't see any "help" here...
>>
>>
>> Woj>To an operator and implementer, it would be very advantageous that
>> all of IPv4 in IPv6 and NAT44 data plane aspects, as specified by
>> Softwire drafts are the same, unless it is made clear as to why they
>> should be different, and what does it bring. This applies especially to
>> lw46 and MAP, since there is so much overlap between the solutions.
>>
>>
>>      Additional comment Now that you mention it, the stated
>>>     characterisation of map isn't quite right; MAP does not force the
>>>     use of mesh mode, nor is mesh mode its defining characteristic.
>>>
>>
>>     [Qi] From my reading, the text doesn't characterize what MAP is. It
>>     just says "if you want to use meshed IPv4 connectivity, then use
>>     MAP". It doesn't prevent you from using MAP to do anything else. So
>>     I think the text is OK.
>>
>>
>> Woj> Well, that is "characterisation". From dictionary: "The act of
>> describing the character or qualities of someone or something"
>> And as stated, it is not quite correct, i.e. mesh-mode is not the
>> defining feature of MAP. The state optimization (stateless) is, of which
>> mesh mode is a by product (optional actually in the spec). The text
>> needs to be changed.
>>
>>
>>      The characterisation should be restated as " lw46 does not seek to
>>>     offer the optimization of AFTR subscriber state and the AFTR is
>>>     expected to have configuration state for each lwB4 node. If
>>>     optimization of this state is required, [id-ietf-softwire-map]
>>>     provides a suitable solution ".
>>>     Alternatively, state that "lw46 describes a
>>>     deployment/implementation of MAP 1:1"
>>>
>>>>
>>>>
>>>>
>>>>>             Detailed comments:
>>>>>
>>>>>             * Section 5.1 WAN prefix selection and address forming -
>>>>>             as per Ole's comment. This is indeed hand wavy in the
>>>>>             current draft (how to select the WAN?)
>>>>>
>>>>>             [ian] I’ve updated with the wording that I proposed to Ole.
>>>>>
>>>>>             The CPE WAN interface is a fairly well used term in a
>>>>>             number of other RFCs. Both RFC6333 and RFC7084 use the
>>>>>             term (and have implementations based on them) without
>>>>>             defining how the CPE has identified it. Why does that
>>>>>             need to be specifically defined here?
>>>>>
>>>>>
>>>>>         Woj>  What is the WAN interface is, and how should the CPE
>>>>>         "find it" not said. That other drafts fail to clarify that
>>>>>         doesn't make it quite right…
>>>>>
>>>>
>>>>
>>>>         [ian] No, this is related to fragmentation in respect to the
>>>>         RFC1858 'Tiny Fragment attack' which affects  the IPv4
>>>>         payload. The same problems exist for the lwB4s NAT44 function
>>>>         as exist for a NAT64 in this respect, which is why it was
>>>>         included.
>>>>
>>>>
>>>>     Woj> Ok, but what does "MAY require" mean, and how should a
>>>>     device go about requiring it?
>>>>
>>>
>>>      [Qi] Please see page 18 of RFC6146:
>>
>>            *  The NAT64 MAY require that the UDP, TCP, or ICMP header be
>>               completely contained within the fragment that contains
>>     fragment
>>               offset equal to zero.
>>
>>
>> Woj> Well, that text as you point comes from NAT64, and concerns IPv6
>> header chain to IPv4 header "fitting". In lwB4, unless I misunderstand,
>> the only fragmentation there may be is that of IPv4 that would be driven
>> by an IPv4 MTU < 40 (violation of IPv4 min MTU 68). So what exactly the
>> draft is requiring here isn't clear.
>> In any case the fragmentation behaviour is not something specific to
>> lw46, so it would be best if you pointed the draft at the source.
>>
>>
>>
>>>>
>>>>             * Section 5.2: Text:
>>>>
>>>>             For incoming de-capsulated IPv4 packets carrying UDP
>>>> packets with a
>>>>
>>>>                 zero checksum, if the lwB4 has enough resources, the
>>>> lwB4 MUST
>>>>
>>>>                 reassemble the packets and MUST calculate the checksum.
>>>>  If the lwB4
>>>>
>>>>                 does not have enough resources, then it MUST silently
>>>> discard the
>>>>
>>>>                 packets.
>>>>
>>>>             Wouldn't it be easier to say that the lwb4 MAY reassemble
>>>>             the packet and recalculate the checksum? It's clearly not
>>>>             a MUST...
>>>>
>>>>             [ian] Why is it not a MUST? If one condition is met you
>>>>             MUST do this, if a different condition is met, you MUST
>>>>             do that. A MAY would make re-assembly of the packets
>>>>             optional, meaning that an implementation could not
>>>>             implement support for fragment reassembly at all and
>>>>             still say that it is compliant with the spec.
>>>>
>>>>
>>>>         If it were a MUST then something would horribly break if it
>>>>         were not done. The above clearly says that this reassembly
>>>>         operation is at the discretion of the device,  subject to an
>>>>         arbitrary "enough resources" condition. If you'd like it to
>>>>         be a MUST then the condition should be removed.
>>>>
>>>
>>>         [ian] Then surely re-assembly is a SHOULD requirement, with a
>>>         a MUST to discard if cannot be re-assembled. As I said, if it
>>>         was a MAY requirement, then implementation would be completely
>>>         optional.
>>>
>>>
>>>     Woj> Yes, and that's what the above text reads from a test
>>>     perspective, i.e. since one has no way of determining whether
>>>     there are "enough resources", a lwB4 that discards all such
>>>     packets would comply. As I said, if one would like to tighten the
>>>     spec; a) the un-testable "enough resources" condition should be
>>>     removed b) with that either a MUST used, if this is something
>>>     super important, or a SHOULD (as it seems to me). Alternatively a
>>>     MAY as "nice to have" may also do.
>>>
>>
>>     [Qi] I prefer to use a SHOULD for re-asembly and a MUST for
>>     discarding the packet if it cannot be reassembled.
>>
>>
>> Woj> Well, so it's a SHOULD then. Please note: the "enough resources"
>> condition as is, is un-testable across implementations, so adding such
>> "dead" text is rather pointless.
>>
>> Cheers,
>> Wojciech.
>>
>>
>> _______________________________________________
>> Softwires mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/softwires
>>
>>
>

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 3 Mar 2014 14:47:55 +0100

Hi Ian,

following up with some proposed text re relation to MAP

> On 26 February 2014 10:31, <[email-masked]> wrote:
>
>> Hi Woj,
>>
>> I've been out of the office for a couple of days, so sorry for the be
>> late reply.
>>
>> Please see inline.
>>
>> Cheers,
>> Ian
>>
>> From: Wojciech Dec <[email-masked]>
>> Date: Wednesday, 19 February 2014 09:34
>> To: Ian Farrer <[email-masked]>
>> Cc: Softwires-wg <[email-masked]>
>> 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 a capability that can be signalled using the lw46 container,
>> etc).
>>
>> [ian] It would help if you could propose text for what you would like to
>> see. The inline discussion has become quite protracted.
>>
>
> I'll follow up on that...
>
>
>>
>>
Here I'm pointing out that IPinIP dataplane + ICMP wise there should be no
difference between lw46 and MAP-E, and in effect a single BR or lw46 AFTR
implementation can be made of these.

Current text in Section 1 reads:

Lightweight 4over6 provides a solution for a hub-and-spoke softwire
   architecture only.  It does not offer direct, meshed IPv4
   connectivity between subscribers without packets traversing the AFTR.
   If this type of meshed interconnectivity is required,
   [I-D.ietf-softwire-map
<http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-07#ref-I-D.ietf-softwire-map>]
provides a suitable solution.

Propose changing the above to:

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, as well as the option of meshed IPv4
connectivity between subscribers, are features of the
[I-D.ietf-softwire-map
<http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-07#ref-I-D.ietf-softwire-map>]
solution.

Cheers,

Wojciech.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Mar 2014 13:54:45 +0000

On Mar 3, 2014, at 1:47 PM, Wojciech Dec <[email-masked]> wrote:
> Lightweight 4over6 provides a solution for a hub-and-spoke softwire architecture only, 
> connectivity between subscribers, are features of the [
> I-D.ietf-softwire-map] solution.

This sounds like a marketing change, not an ICMP change.   Can you explain what this has to do with ICMP?

---

From: Ian Farrer <[email-masked]>
Date: Mon, 3 Mar 2014 14:02:15 +0000

> 
> There is a difference: Here I'm pointing out that IPinIP dataplane + ICMP wise there should be no difference between lw46 and MAP-E, and in effect a MAP BR or lw46 AFTR implementation of these would be no different. There is no talk of provisioning.
> uCPE attempts to bring in all mechanisms, also beyond -E and lw46, + their various provisioning options for a single CPE. 
> 

[ian] To be clear about where (I think) we are with this - the data plane behaviour between MAP-E & lw4o6 are the same, the only thing that we need to get agreement on is the wording that’s used to describe it.

Is that your understanding as well?

Cheers,
Ian

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 3 Mar 2014 15:10:43 +0100

On 3 March 2014 14:54, Ted Lemon <[email-masked]> wrote:

>From a previous mail (that you perhaps missed):
Woj> the stated characterisation of map isn't quite right; MAP does not
force the use of mesh mode, nor is mesh mode its defining characteristic.
The characterisation should be restated as...

Like others, please treat it like a WG LC comment.

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 3 Mar 2014 14:19:58 +0000

Sorry for my ignorance. How MAP-E optimizes states In hub-and-spoke mode
compared to lw4o6? 

From:  Wojciech Dec <[email-masked]>
Date:  Monday, March 3, 2014 at 1:47 PM
To:  "[email-masked]" <[email-masked]>
Cc:  Softwires-wg <[email-masked]>
Subject:  Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt

Hi Ian,

>> I¹ve been out of the office for a couple of days, so sorry for the be late
>> reply.
>> 
>> Please see inline.
>> 
>> Cheers,
>> 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).
>> 
>> [ian] It would help if you could propose text for what you would like to see.
>> The inline discussion has become quite protracted.
> 

Lightweight 4over6 provides a solution for a hub-and-spoke softwire
   architecture only.  It does not offer direct, meshed IPv4
   connectivity between subscribers without packets traversing the AFTR.
   If this type of meshed interconnectivity is required,
   [I-D.ietf-softwire-map
<http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-07#ref-I-D.ietf-sof
twire-map> ] provides a suitable solution.

connectivity between subscribers, are features of the [I-D.ietf-softwire-map
<http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-07#ref-I-D.ietf-sof
twire-map> ] solution.

Cheers,
Wojciech.

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 3 Mar 2014 15:20:20 +0100

It done by having 1 rule for N CEs, i.e. route aggregation vs host routes

On 3 March 2014 15:19, Lee, Yiu <[email-masked]> wrote:

>>> 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).
>>>
>    [I-D.ietf-softwire-map <http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-07#ref-I-D.ietf-softwire-map>] provides a suitable solution.
>
>
> connectivity between subscribers, are features of the [I-D.ietf-softwire-map <http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-07#ref-I-D.ietf-softwire-map>] solution.
>
> Cheers,
>
> Wojciech.
>
>
>
>

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 3 Mar 2014 23:21:15 +0900

CE Just send packet to BR.
--satoru

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 3 Mar 2014 15:22:14 +0100

> It done by having 1 rule for N CEs, i.e. route aggregation vs host routes

Oh, and it still stays hub & spoke, unless the CE is also set-up for mesh
mode.

>>>> [ian] It would help if you could propose text for what you would like
>>>> to see. The inline discussion has become quite protracted.
>>>>
>>>
>> Here I'm pointing out that IPinIP dataplane + ICMP wise there should be
>> no difference between lw46 and MAP-E, and in effect a single BR or lw46
>> AFTR implementation can be made of these.
>>

---

From: Ian Farrer <[email-masked]>
Date: Mon, 3 Mar 2014 14:37:24 +0000

[ian] So if you are optimising the amount of state, then you are doing this at the expense of reduced flexibility in v4/v6 address mapping. In the interest of balance, it would be fair to point this out.

Cheers,
Ian

On 3 Mar 2014, at 14:22, Wojciech Dec <[email-masked]> wrote:

> Oh, and it still stays hub & spoke, unless the CE is also set-up for mesh mode.
> 
> 
> Sorry for my ignorance. How MAP-E optimizes states In hub-and-spoke mode compared to lw4o6? 
> 
> I’ve been out of the office for a couple of days, so sorry for the be late reply.
> 
> Please see inline.
> 
> Cheers,
> 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).
> 
> [ian] It would help if you could propose text for what you would like to see. The inline discussion has become quite protracted. 
> 
> Here I'm pointing out that IPinIP dataplane + ICMP wise there should be no difference between lw46 and MAP-E, and in effect a single BR or lw46 AFTR implementation can be made of these.
> 
> connectivity between subscribers, are features of the [I-D.ietf-softwire-map] solution.
> 
> 
> 
> Cheers,
> Wojciech.
> 
>  
> 
>

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 3 Mar 2014 23:48:24 +0900

On Mon, Mar 3, 2014 at 11:37 PM, Ian Farrer <[email-masked]> wrote:

> [ian] So if you are optimising the amount of state, then you are doing
> this at the expense of reduced flexibility in v4/v6 address mapping. In the
> interest of balance, it would be fair to point this out.
>
>
I couldn't understand your point. Address mapping flexibility is
independent from whether it is in H&S operation or not.
--satoru

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 3 Mar 2014 15:52:29 +0100

> interest of balance, it would be fair to point this out.

It' just like ip route aggregation/subnetting with a next hop, which
requires the aggregated ip range represented by the route to be contiguous.
Furthermore, milage on how much of such optimization is desired or
possible, will vary from operator to operator, just like the way operators
have different subnetting plans/constraints

Anyway, how about this text then?

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 as the option of meshed IPv4

-Wojciech.

---

From: Qi Sun <[email-masked]>
Date: Mon, 3 Mar 2014 15:13:18 +0000

Firstly, I still don't understand how MAP-E 'optimize' the state compared to lw4o6. There are so many modes in MAP, which are you talking about?
Secondly, does the word 'optimize' means 'something is better than the other'? But looking back to the IESG's abstentions on the draft stateless-motivation, there was no clear reason why stateless is 'better than' stateful. (NOT trying to bring up issues two years old. Just think it might be good to avoid subjective wording in a protocol... )

Best Regards,
Qi

On 2014-3-3, at 下午2:52, Wojciech Dec wrote:

> It' just like ip route aggregation/subnetting with a next hop, which requires the aggregated ip range represented by the route to be contiguous. Furthermore, milage on how much of such optimization is desired or possible, will vary from operator to operator, just like the way operators have different subnetting plans/constraints
> 
> optmizing the amount of such state using IPv4-IPv6 address mapping rules, as well as the option of meshed IPv4 
>

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 4 Mar 2014 01:12:12 +0900

On Tue, Mar 4, 2014 at 12:13 AM, Qi Sun <[email-masked]> wrote:

>
> Firstly, I still don't understand how MAP-E 'optimize' the state compared
> to lw4o6. There are so many modes in MAP, which are you talking about?
> Secondly, does the word 'optimize' means 'something is better than the
> other'? But looking back to the IESG's abstentions on the draft
> stateless-motivation, there was no clear reason why stateless is 'better
> than' stateful. (NOT trying to bring up issues two years old. Just think it
> might be good to avoid subjective wording in a protocol... )
>

You can chage whole Internet to full stateful network which has google,
amazon, facebook, etc., as the hubs.
--satoru

>>>>>> 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).
>>>>>>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Mar 2014 15:40:18 +0000

> 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 situation where a reader of this specification decides to implement it rather than a hub-and-spoke-only subset of MAP, even though MAP provides hub-and-spoke as well as the mesh mode.

But in practice, someone who does not want to implement full MAP probably _is_ going to prefer lw4over6.   Someone who reads both specs, wants to implement MAP anyway, and is seeing no market pressure to implement lw4over6 isn't going to decide to implement lw4over6 as well because of this text.

So I think the text actually says the right thing as currently written, and is likely to be more confusing to the intended reader with your proposed change.  That's my opinion as a participant, not as AD—if the working group disagrees with me, I'm totally okay with that.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 03 Mar 2014 16:46:02 +0000

> connectivity between subscribers, are features of the [I-D.ietf-softwire-map <http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-07#ref-I-D.ietf-softwire-map>] solution.

Optimality is in the eye of the operator.

What MAP does is *minimize* the amount of state at the cost of
flexibility. It may be more or less optimal depending on what you need.

Suggestion: create a two-axis ASCII graph labeled "state" and
"flexibility". Put MAP, lw4o6, and heck even DS-Lite in it at the
appropriate spots.

(This is not wordsmithing since I'm proposing a figure. It's
figure-smithing.)

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 3 Mar 2014 16:57:36 +0000

How MAP-E aggregates CPE for N CEs in hub-and-spoke? When implementing MAP
in hub-and-spoke, cpe/ce v4 information is in the br. Each ce will have an
entry in the br. This is the same number of states lw4o6 will maintain. Am I
missing something? I support to keep the original text in the draft.

From:  Wojciech Dec <[email-masked]>
Date:  Monday, March 3, 2014 at 2:20 PM
To:  "Yiu L. LEE" <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>, Softwires-wg
<[email-masked]>
Subject:  Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt

On 3 March 2014 15:19, Lee, Yiu <[email-masked]> wrote:
>>> believe it does in this draft, also leaving "as-is" the DHCP part of it
> <http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-07#ref-I-D.ietf-softw
> ire-map> ] provides a suitable solution.
>  
> <http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-07#ref-I-D.ietf-softw
> ire-map> ] solution.
> 
> Cheers,
> Wojciech.
> 
>

---

From: <[email-masked]>
Date: Mon, 3 Mar 2014 17:57:42 +0100

Sounds like we are time warped back to the Taipeh and Paris IETF where we had this discussion in all levels of detail ? 
We (==operator) needed more flexibility than MAP could offer and were willing to accept the cost of managing some state... Woj did not want to hear it by then, and this seems to be a never-ending story... :-).

If a figure helps to document that, fine. Just avoid to get back to square 1.

Axel

-----Original Message-----
From: Softwires [mailto:[email-masked]] On Behalf Of Simon Perreault
Sent: Monday, March 03, 2014 5:46 PM
To: [email-masked]
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt

Le 2014-03-03 14:52, Wojciech Dec a écrit :
> 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 as the option of meshed IPv4 connectivity between subscribers, are features of the [I-D.ietf-softwire-map <http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-07#ref-I-D.ietf-softwire-map>] solution.

What MAP does is *minimize* the amount of state at the cost of flexibility. It may be more or less optimal depending on what you need.

Suggestion: create a two-axis ASCII graph labeled "state" and "flexibility". Put MAP, lw4o6, and heck even DS-Lite in it at the appropriate spots.

Simon

---

From: Ian Farrer <[email-masked]>
Date: Mon, 3 Mar 2014 18:54:55 +0000

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 the behavior for ICMP message conforming to the
>    best current practice documented in [RFC5508]. 
> If a LwB4 receives an ICMP error message without the ICMP
>    identifier field for errors that is detected inside a IPv6 tunnel, the
>    node should relay the ICMP error message to the original source.
>    This behavior SHOULD be implemented conforming to the section 8 of
>    [RFC2473].
>  FOr TCP and UDP traffic the NAT44 implemented in the LwB4 SHOULD conform with the behavior
>    and best current practice documented in [RFC4787], [RFC5508], and
>    [RFC5382].  
> 

What about the following wording, tweaked after reading RFC6888 (Common Reqs for CGNs), replacing Section 5.2:
---
For TCP and UDP traffic the NAPT44 implemented in the lwB4 SHOULD conform with the behaviour and best current practices documented in
[RFC4787], [RFC508], and [RFC5382]. If the lwB4 supports DCCP, then the requirements in [RFC5597] SHOULD be implemented.

The NAPT44 in the lwB4 MUST implement ICMP message handling behaviour conforming to the best current practice documented in [RFC5508]
If the lwB4 receives an ICMP message without the ICMP identifier field for errors detected inside the IPv6 tunnel, the node should relay
the ICMP error message to the original source (the lwAFTR).

This behaviour SHOULD be implemented conforming to the section 8 of [RFC2473].
----

@Senthil, as this is a change to the wording previously agreed, could you let me know if you’re OK with the proposed new text?

Cheers,
Ian

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Mon, 3 Mar 2014 19:16:19 +0000

Hi Ian,

Does the highlighted part mean "If the lwB4 receives an ICMP error message", if so can you replace it as suggested?
I am not really sure why icmp identifier field is mentioned in there. Other than that I am ok with the text.

Thanks
Senthil

From: Ian Farrer <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 3, 2014 1:54 PM
To: Wojciech Dec <[email-masked]<mailto:[email-masked]>>, Senthil Sivakumar <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Softwires-wg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt

Hi Woj / Senthil,

Suggested text:

The NAT44 in the lwB4 MUST implement the behavior for ICMP message conforming to the
   best current practice documented in [RFC5508<http://tools.ietf.org/html/rfc5508>].
If a LwB4 receives an ICMP error message without the ICMP
   identifier field for errors that is detected inside a IPv6 tunnel, the
   node should relay the ICMP error message to the original source.
   This behavior SHOULD be implemented conforming to the section 8 of
   [RFC2473]<http://tools.ietf.org/html/rfc2473#section-8>.
 FOr TCP and UDP traffic the NAT44 implemented in the LwB4 SHOULD conform with the behavior
   and best current practice documented in [RFC4787<http://tools.ietf.org/html/rfc4787>], [RFC5508<http://tools.ietf.org/html/rfc5508>], and
   [RFC5382<http://tools.ietf.org/html/rfc5382>].

Cheers,
Ian

---

From: Ian Farrer <[email-masked]>
Date: Mon, 3 Mar 2014 19:40:15 +0000

Hi Senthil,

Good point. So, that would give us:

> If the lwB4 receives an ICMP error (for errors detected inside the IPv6 tunnel), the node should relay

Works for me. OK with you Woj?

Cheers,
Ian

On 3 Mar 2014, at 19:16, Senthil Sivakumar (ssenthil) <[email-masked]> wrote:

> From: Ian Farrer <[email-masked]>
> To: Wojciech Dec <[email-masked]>, Senthil Sivakumar <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, Softwires-wg <[email-masked]>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Mar 2014 19:44:16 +0000

> (This is not wordsmithing since I'm proposing a figure. It's

Which document would have to have this figure in it?   :)

---

From: Simon Perreault <[email-masked]>
Date: Mon, 03 Mar 2014 19:47:24 +0000

> Which document would have to have this figure in it?   :)

Ah, I don't know, maybe the working group charter? >:-)

(Was semi-joking, am fully joking now.)

Simon

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Mar 2014 20:03:33 +0000

> (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 I'm kind of joking, but I'd really like to get this work done, so I can be flexible on the charter question... :)

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 4 Mar 2014 09:36:01 +0100

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,
[I-D.ietf-softwire-map<http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-07#ref-I-D.ietf-softwire-map>]
provides a suitable solution.", alongside  a previous point of "

The reduction of maintained state results in a greatly reduced
      logging overhead on the service provider."

Hence re-stating: The defining characteristic of MAP is the optimization,
or reduction if you prefer, of state via route aggregation. A by product of
this also the optional mesh mode.
Since the lw46 draft mentions that reduction of state is "greatly reduced"
in positive terms, the text that I proposed is justified.
Needless to say I do not agree with the current text, as it paints an
incorrect picture to the reader of this space.

As discussed with Ian, I'm willing to support text in the MAP-E draft along
the lines of  "the per-subscriber (1:1 mapping) rule case is further
detailed in lw46", etc.
This seemed like a reasonable re-solution to me and Ian.

Regards,
Wojciech.

On 3 March 2014 16:40, Ted Lemon <[email-masked]> wrote:

> 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 situation where a reader of
> this specification decides to implement it rather than a hub-and-spoke-only
> subset of MAP, even though MAP provides hub-and-spoke as well as the mesh
> mode.
>
> But in practice, someone who does not want to implement full MAP probably
> _is_ going to prefer lw4over6.   Someone who reads both specs, wants to
> implement MAP anyway, and is seeing no market pressure to implement
> lw4over6 isn't going to decide to implement lw4over6 as well because of
> this text.
>
> So I think the text actually says the right thing as currently written,
> and is likely to be more confusing to the intended reader with your
> proposed change.  That's my opinion as a participant, not as AD--if the
> working group disagrees with me, I'm totally okay with that.
>
>

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 4 Mar 2014 09:41:02 +0100

On 3 March 2014 17:57, Lee, Yiu <[email-masked]> wrote:

> entry in the br. This is the same number of states lw4o6 will maintain. Am
> I missing something? I support to keep the original text in the draft.
>

You appear to be confusing the relation between hub&spoke and number of BR
rules.
In MAP optimized + hub&spoke mode the following applies:
- Each CE has just 1 DMR (aka default rule, aka default route). Mesh mode
is not active in this case
- Each BR has just 1 forwarding rule for the N CE's that are part of its
domain. That changes to N rules in the 1:1 case.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Mar 2014 09:20:55 +0000

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 to be, for two reasons.   First, this is not a draft about MAP.   Secondly, everybody already knows what they intend to implement anyway, so getting this text exactly perfect will make not one iota of difference in regards to who implements what.

---

From: Ole Troan <[email-masked]>
Date: Tue, 4 Mar 2014 09:42:22 +0000

> 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 boilerplat…

I have had success in the past by removing contentious text. I think that could work here, just remove this paragraph:

"It does not offer direct, meshed IPv4 connectivity between subscribers without packets traversing the AFTR.
If this type of meshed interconnectivity is required, [I-D.ietf-softwire-map] provides a suitable solution."

or alternatively, the last sentence.

cheers,
Ole

---

From: Ian Farrer <[email-masked]>
Date: Tue, 4 Mar 2014 09:54:59 +0000

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 completed, so there’s something to actually compare)?

A basket of vipers, I’m sure, but it wold give somewhere for a much more complete analysis of the pros and cons rather than a line and a half of analysis in the technology specific drafts.

Ian

Discretion is the better part of valour.

I would be happy with this as a possible solution.

I think that there’s a need for an overall softwire doc that tackles the

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 4 Mar 2014 11:04:51 +0100

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. It is the right thing to do, esp in IETF standard track drafts for which
a higher bar applies (or should).

On 4 March 2014 10:54, Ian Farrer <[email-masked]> wrote:

> This could certainly save a spending the rest of the week micro-editing
> wording, so I'd be happy with it.
>
> 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, but it wold give somewhere for a much more
> complete analysis of the pros and cons rather than a line and a half of
> analysis in the technology specific drafts.
>
> Ian
>
>
> I think that there's a need for an overall softwire doc that tackles the
>
> >> 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 to be, for two reasons.   First, this is not a draft about MAP.
> Secondly, everybody already knows what they intend to implement anyway, so
> getting this text exactly perfect will make not one iota of difference in
> regards to who implements what.
> >
> > I have had success in the past by removing contentious text. I think
> that could work here, just remove this paragraph:
> >
> [I-D.ietf-softwire-map] provides a suitable solution."
> >

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Mar 2014 10:07:14 +0000

> 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. :)

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Mar 2014 10:13:29 +0000

> A basket of vipers, I’m sure, but it wold give somewhere for a much more complete analysis of the pros and cons rather than a line and a half of analysis in the technology specific drafts.

The good thing about this is that there is no time pressure; even if there may be some future need for this document, there is no current need for the current round of implementors, whereas getting the base specs out is pretty important.

Of course, the bad thing about this is that there is no time pressure, and I would hate to see softwire spend the next two or four years arguing about this document.

But with those caveats in mind, this sounds like a good idea.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Mar 2014 10:18:13 +0000

> 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_ then you do have some degree of veto power, but this point doesn't rise to that level.

The text here only functions to explain to a person who is not familiar with either draft which draft they should implement.   In that unlikely scenario, the text as written does not give sufficient guidance.   In order to meet that need, the text would have to be more like what Ian is describing.

So if that is in fact the use case you are shooting for, I think you should work with Ian on the draft he's proposed.   There is no way to get that by wordsmithing this text.

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 4 Mar 2014 11:26:48 +0100

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). Perhaps
it's not your intent, but you're actually flaming the flames here...

On 4 March 2014 11:18, Ted Lemon <[email-masked]> wrote:

> 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_ then you do have some degree of veto power, but
> this point doesn't rise to that level.
>
> The text here only functions to explain to a person who is not familiar
> with either draft which draft they should implement.   In that unlikely
> scenario, the text as written does not give sufficient guidance.   In order
> to meet that need, the text would have to be more like what Ian is
> describing.
>
> So if that is in fact the use case you are shooting for, I think you
> should work with Ian on the draft he's proposed.   There is no way to get
> that by wordsmithing this text.
>
>

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 4 Mar 2014 11:31:12 +0100

Yes, for the ICMP handling part, this works for me.

Cheers

On 3 March 2014 20:40, Ian Farrer <[email-masked]> wrote:

> For TCP and UDP traffic the NAPT44 implemented in the lwB4 SHOULD conform
> with the behaviour and best current practices documented in
> [RFC4787], [RFC508], and [RFC5382]. If the lwB4 supports DCCP, then the
> requirements in [RFC5597] SHOULD be implemented.
>
> The NAPT44 in the lwB4 MUST implement ICMP message handling behaviour
> conforming to the best current practice documented in [RFC5508]
>  The NAPT44 in the lwB4 MUST implement ICMP message handling behaviour
> conforming to the best current practice documented in [RFC5508]
> If the lwB4 receives an ICMP message without the ICMP identifier fieldfor errors detected inside the IPv6 tunnel, the node should relay
>  Does the highlighted part mean "If the lwB4 receives an ICMP error
> message", if so can you replace it as suggested?
>  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:
>
>    best current practice documented in [RFC5508 <http://tools.ietf.org/html/rfc5508>].
>    [RFC2473] <http://tools.ietf.org/html/rfc2473#section-8>.
>    and best current practice documented in [RFC4787 <http://tools.ietf.org/html/rfc4787>], [RFC5508 <http://tools.ietf.org/html/rfc5508>], and
>    [RFC5382 <http://tools.ietf.org/html/rfc5382>].
>
>        What about the following wording, tweaked after reading RFC6888
> (Common Reqs for CGNs), replacing Section 5.2:
> ---
>  For TCP and UDP traffic the NAPT44 implemented in the lwB4 SHOULD
> conform with the behaviour and best current practices documented in
> [RFC4787], [RFC508], and [RFC5382]. If the lwB4 supports DCCP, then the
> requirements in [RFC5597] SHOULD be implemented.
>
>  The NAPT44 in the lwB4 MUST implement ICMP message handling behaviour
> conforming to the best current practice documented in [RFC5508]
> If the lwB4 receives an ICMP message without the ICMP identifier field for
> errors detected inside the IPv6 tunnel, the node should relay
>  @Senthil, as this is a change to the wording previously agreed, could
> you let me know if you're OK with the proposed new text?
>
>  Cheers,
> Ian
>
>
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Mar 2014 10:34:24 +0000

On Mar 4, 2014, at 10:26 AM, Wojciech Dec <[email-masked]> 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 will take years to resolve,  took 5 mins to agree with Ian (yesterday). Perhaps it's not your intent, but you're actually flaming the flames here... 

If the authors are satisfied with your proposed text, my comments can be ignored (indeed, they can be ignored anyway—as I already said, I am not speaking as an AD in this discussion).   I am not under the impression that the authors are satisfied with your proposed text, which is why I've made some suggestions about alternative ways to proceed.

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 4 Mar 2014 09:47:28 -0500

Hi Ian,

> A basket of vipers, I’m sure, but it wold give somewhere for a much more complete analysis of the pros and cons rather than a line and a half of analysis in the technology specific drafts.

I think could be an useful effort but I do think that writing an 
objective document is going to be extremely hard. I think we will have 
problems even agreeing on the axes of comparison, let alone the 
evaluation of the solutions along these axes.

Thanks
Suresh

---

From: Ole Troan <[email-masked]>
Date: Tue, 4 Mar 2014 14:27:03 +0000

> I think could be an useful effort but I do think that writing an objective document is going to be extremely hard. I think we will have problems even agreeing on the axes of comparison, let alone the evaluation of the solutions along these axes.

I agree with Suresh. the outcome of the working group is to publish 5 largely equal mechanisms. then it is up to the market to decide which mechanism will be successful. I don't really see what more the IETF can do to contribute to that process.

cheers,
Ole

---

From: Ian Farrer <[email-masked]>
Date: Tue, 4 Mar 2014 17:32:46 +0000

OK, it was merely a suggestion….

I’m mildly relieved I don’t have to write it.

Ian

---

From: Tom Taylor <[email-masked]>
Date: Tue, 04 Mar 2014 13:11:13 -0500

On 04/03/2014 9:47 AM, Suresh Krishnan wrote:
>> This could certainly save a spending the rest of the week
>> micro-editing wording, so I’d be happy with it.
>>
>> 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, but it wold give somewhere for a much
>> more complete analysis of the pros and cons rather than a line and a
>> half of analysis in the technology specific drafts.
>
I'd be willing to tackle an initial version as an intellectual exercise.

Tom Taylor

---

From: Ian Farrer <[email-masked]>
Date: Wed, 5 Mar 2014 14:29:50 +0000

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 draft. 
> What more however is that the text does not describe how a case of a WAN without a global IPv6 prefix is to be handled (is that also invalid - please state so in the draft). 
> Other cases: 
> - What is the WAN doesn't have a /64? 
> - What if there are multiple WAN interfaces?
> 
> If these are all invalid w/ lw46 - then please state so.
> 

[for Section 5.1]

For DHCPv6 based configuration of these parameters, the lwB4 SHOULD
implement OPTION_S46_CONT_LW as described in section 6.3 of
[I-D.ietf-softwire-map-dhcp].  This means that the lifetime of the
softwire and the derived configuration information (e.g. IPv4 shared
address, IPv4 address) is bound to the lifetime of the DHCPv6 lease.
If stateful IPv4 configuration or additional IPv4 configuration
information is required, DHCPv4 [RFC2131] must be used.

The received DHCPv6 lw4o6 configuration is applicable only to the interface
from which the DHCP Solicit message was sourced. Although it would be possible to
extend lw4o6 to have more than one active WAN interface and corresponding 
lw4o6 tunnels configured simultaneously, this document is only concerned with 
the use of a single interface and tunnel.

On receipt of OPTION_S46_CONT_LW, the lwB4 performs a longest prefix match 
between the IPv6 address of the lwAFTR (contained in OPTION_S46_BR) and the 
configured prefixes on the interface that originated the DHCP solicit message.
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.
If no matching prefix of the same IPv6 scope (as described by [RFC4007]), then
the lwB4 MUST NOT attempt to configure the softwire tunnel interface. 

If a change in the interface addressing occurs, then the tunnel interface 
configuration process MUST be restarted.

The result forms the subnet to be used for sourcing the lw4o6 tunnel. The full
/128 prefix is then constructed in the same manner as [I-D.ietf-softwire-map].

---

From: Simon Perreault <[email-masked]>
Date: Wed, 05 Mar 2014 14:34:57 +0000

> 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

---

From: Ian Farrer <[email-masked]>
Date: Wed, 5 Mar 2014 14:38:11 +0000

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

---

From: Simon Perreault <[email-masked]>
Date: Wed, 05 Mar 2014 14:40:52 +0000

Fine then.

Simon

---

From: Ole Troan <[email-masked]>
Date: Wed, 5 Mar 2014 14:56:23 +0000

Ian,

> 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 couldn't do it as MAP does?

- include a "Domain IPv6 prefix" in the set of provisioning parameters.
- the client does a longest match between the Domain IPv6 prefix and the End-user IPv6 prefixes
  and uses that to create the tunnel end point address.

that also allows the operator to use either the WAN side /64 or an address out of the PD as the tunnel endpoint address.

cheers,
Ole

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 5 Mar 2014 16:14:22 +0000

Agreed with your statements. When I wrote the previous email, I looked at it
from the 4o6 angle.  I was questioning how was MAP-E more optimized in the
4o6 mode. I over-generalized hub-and-spoke in my question. My bad.

Date:  Tuesday, March 4, 2014 at 8:41 AM

On 3 March 2014 17:57, Lee, Yiu <[email-masked]> wrote:
> How MAP-E aggregates CPE for N CEs in hub-and-spoke? When implementing MAP in
> hub-and-spoke, cpe/ce v4 information is in the br. Each ce will have an entry
> in the br. This is the same number of states lw4o6 will maintain. Am I missing
> something? I support to keep the original text in the draft.

- Each CE has just 1 DMR (aka default rule, aka default route). Mesh mode is
not active in this case

---

From: Qi Sun <[email-masked]>
Date: Wed, 5 Mar 2014 16:17:37 +0000

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

---

From: Ian Farrer <[email-masked]>
Date: Wed, 5 Mar 2014 16:23:23 +0000

Hi Ole,

See inline.

Cheers,
Ian

> I'm not comfortable with that.

[ian] Why aren’t you comfortable with it?

---

From: Ole Troan <[email-masked]>
Date: Wed, 5 Mar 2014 17:51:13 +0000

Ian,

> [ian] Why aren’t you comfortable with it?

I thought that was obvious.
- it reinvents the wheel
- and it reinvents a wheel that is less round than the one already invented.

is there any reason why you cannot use the existing wheel?
or feel free to invent a better one, and we can adopt that for MAP.

cheers,
Ole

---

From: "Yuchi Chen" <[email-masked]>
Date: Thu, 6 Mar 2014 16:00:04 +0800

Hi Ole,

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 lwB4 has been provisioned with such an address, and if this address does have a LPM with lwAFTR's address, lwB4 can still use it as the tunnel endpoint address. Please correct me if I'm missing anything.

Regards,
--------------
Yuchi

On 2014-03-06, 01:51, "Ole Troan" <[email-masked]> wrote:
>>>> The lwAFTR never has to do the LPM. It抯 just got a tunnel endpoint address configured by the operator.
>>> 
>> [ian] Why aren抰 you comfortable with it?
>

---

From: Tina TSOU <[email-masked]>
Date: Thu, 6 Mar 2014 09:41:05 +0000

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" <[email-masked]<mailto:[email-masked]>> wrote:

On Mar 3, 2014, at 1:47 PM, Wojciech Dec <[email-masked]<mailto:[email-masked]>> 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 for
optmizing the amount of such state, as well as the option of meshed IPv4

_______________________________________________
Softwires mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/softwires

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 6 Mar 2014 11:28:52 +0100

Qi,

On 5 March 2014 17:17, Qi Sun <[email-masked]> 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.
>

The point is that such state optimization is possible, using v4-v6 address
mapping, which is a characteristic of MAP and mesh mode which the current
text refers to is its by product.

We have with Ian a new adequate sentence which fixes things, and I'll let
Ian post it. It is important to have such text for at least the following
reason:
The solutions have much in common; utilize the same MAP PSID algorithm
(although with different defaults), encap, etc. They're not thus
orthogonal, and while some may wish to implement them independently, which
is possible there is enough commonality to warrant to "pointer text".

A side note
In both lw4over6  and MAP the IPv4 address+PSID are embedded in the IPv6
address of a CE. So your statement of "totally decoupled" isn't quite
accurate.

Cheers,
Wojciech.

---

From: Ian Farrer <[email-masked]>
Date: Thu, 6 Mar 2014 11:27:46 +0000

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 to IPv6 address mappings to create aggregate rules. This also gives the option of direct meshed IPv4 connectivity between subscribers."

My position on this is that I am fine with the text above, I’m happy with a wordsmithed version that is mutually agreeable and I am also fine with the text being removed altogether.

Whichever one can get us past this point is the right answer.

Ian

On 6 Mar 2014, at 10:28, Wojciech Dec <[email-masked]> wrote:

> The point is that such state optimization is possible, using v4-v6 address mapping, which is a characteristic of MAP and mesh mode which the current text refers to is its by product. 
> 
> We have with Ian a new adequate sentence which fixes things, and I'll let Ian post it. It is important to have such text for at least the following reason: 
> The solutions have much in common; utilize the same MAP PSID algorithm (although with different defaults), encap, etc. They're not thus orthogonal, and while some may wish to implement them independently, which is possible there is enough commonality to warrant to "pointer text". 
> 
> A side note 
> In both lw4over6  and MAP the IPv4 address+PSID are embedded in the IPv6 address of a CE. So your statement of "totally decoupled" isn't quite accurate.
> 
> Cheers,
> Wojciech.
>  
> 
> Best Regards,
> Qi
> 
>

---

From: Ole Troan <[email-masked]>
Date: Thu, 6 Mar 2014 13:10:13 +0000

Yuchi,

> 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 lwB4 has been…

there are two issues here.

1) in the unified CPE context. is there a benefit in having the same algorithm to choose the CE tunnel endpoint address?
    are the requirements different?
2) pick the right mechanism for tunnel end point determination. in your above scheme you do not have the same flexibility as you have with a provisioned prefix selector 

I though we had covered one in previous discussions, but there might be something I've missed.
are we in agreement on this point? that it is beneficial to use the same mechanism for tunnel endpoint address determination on the CE.

cheers,
Ole

---

From: Tom Taylor <[email-masked]>
Date: Thu, 06 Mar 2014 08:26:55 -0500

> are we in agreement on this point? that it is beneficial to use the same mechanism for tunnel endpoint address determination on the CE.
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.

Tom Taylor

---

From: Ian Farrer <[email-masked]>
Date: Thu, 6 Mar 2014 13:33:06 +0000

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

---

From: Ole Troan <[email-masked]>
Date: Thu, 6 Mar 2014 13:35:38 +0000

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 pretty sure you don't actually mean this. ;-))

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Thu, 6 Mar 2014 13:37:32 +0000

Ian,

> 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 that we use the same wheel if we can.
if you have invented a better wheel, then I would like to use it in MAP-E as well.

cheers,
Ole

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 6 Mar 2014 14:41:24 +0000

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 <[email-masked]>
Date:  Thursday, March 6, 2014 at 11:27 AM
To:  Wojciech Dec <[email-masked]>
Cc:  Softwires-wg WG <[email-masked]>
Subject:  Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt

"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 to IPv6 address mappings to create
aggregate rules. This also gives the option of direct meshed IPv4
connectivity between subscribers."

My position on this is that I am fine with the text above, I’m happy with a
wordsmithed version that is mutually agreeable and I am also fine with the
text being removed altogether.

Ian

On 6 Mar 2014, at 10:28, Wojciech Dec <[email-masked]> wrote:

> mapping, which is a characteristic of MAP and mesh mode which the current text
> refers to is its by product.
> 
> We have with Ian a new adequate sentence which fixes things, and I'll let Ian
> post it. It is important to have such text for at least the following reason:
> (although with different defaults), encap, etc. They're not thus orthogonal,
> and while some may wish to implement them independently, which is possible
> there is enough commonality to warrant to "pointer text".
> 
> A side note

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 6 Mar 2014 14:42:28 +0000

Ole, 

A clarification question. Do you suggest to use S46 Rule Option?

Thanks,
Yiu

On 3/6/14, 1:37 PM, "Ole Troan" <[email-masked]> 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 with new fields for prefix6-len and ipv6-prefixes
>>to be used for a LPM, would this meet your definition of a wheel?
>

---

From: Qi Sun <[email-masked]>
Date: Thu, 6 Mar 2014 14:41:15 +0000

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

---

From: Cong Liu <[email-masked]>
Date: Thu, 6 Mar 2014 14:46:45 +0000

+1 for remove the text

Cong

2014-03-06 14:41 GMT+00:00 Lee, Yiu <[email-masked]>:

> I still have problem to include text to compare two methods. Why not
> remove the whole sentence as Ole stated in his email?
>
> Yiu
>
> subscriber. [I-D.ietf-softwire-map] offers a means for optimizing the
> amount of such state by using algorithmic IPv4 to IPv6 address mappings
> to create aggregate rules. This also gives the option of direct meshed
> IPv4 connectivity between subscribers."
>
> My position on this is that I am fine with the text above, I’m happy with
> a wordsmithed version that is mutually agreeable and I am also fine with
> the text being removed altogether.
>

---

From: Qiong <[email-masked]>
Date: Thu, 6 Mar 2014 22:48:35 +0800

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
describe what is lw4o6.

Best wishes
Qiong

-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude

Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/
<http://sourceforge.net/projects/laft6/>*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/
<http://sourceforge.net/projects/pcpportsetdemo/> *
===============================================

---

From: "Yuchi Chen" <[email-masked]>
Date: Thu, 6 Mar 2014 22:56:37 +0800

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

---

From: Ian Farrer <[email-masked]>
Date: Thu, 6 Mar 2014 14:57:12 +0000

OK, so what about the following text?

Although it would be possible to extend lw4o6 to have more than one active  
lw4o6 tunnel configured simultaneously, this document is only concerned with 
the use of a single tunnel.

On receipt of OPTION_S46_CONT_LW, the lwB4 performs a longest prefix match 
between the IPv6 prefix contained in OPTION_S46_IPV4ADDRESS and its currently 
active IPv6 prefixes. The result forms the subnet to be used for sourcing the 
lw4o6 tunnel. The full /128 prefix is then constructed in the same manner as 
[I-D.ietf-softwire-map].

———————————
Obviously, there would need to be the relevant changes to the map-dhpc draft in line with the above.

Cheers,
Ian

---

From: "Yuchi Chen" <[email-masked]>
Date: Thu, 6 Mar 2014 23:17:36 +0800

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 suggest is to remove the entire text.

Best regards!
--------------
Yuchi Chen

---

From: Ole Troan <[email-masked]>
Date: Thu, 6 Mar 2014 15:34:42 +0000

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

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 6 Mar 2014 19:27:58 +0100

> 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 note that MAP-E would get also a suitable pointer to the lw46 draft
concerning the 1:1 mode.

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 6 Mar 2014 19:34:40 +0100

Would you be more comfortable with "reducing"?

On 6 March 2014 16:17, Yuchi Chen <[email-masked]> 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".
>
> amount of such state by using algorithmic IPv4 to IPv6 address mappings to
> create aggregate rules. This also gives the option of direct meshed IPv4
> >> 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.
> >>
> >> The point is that such state optimization is possible, using v4-v6
> address mapping, which is a characteristic of MAP and mesh mode which the
> current text refers to is its by product.
> >>
> >> We have with Ian a new adequate sentence which fixes things, and I'll
> let Ian post it. It is important to have such text for at least the
> following reason:
> >> In both lw4over6  and MAP the IPv4 address+PSID are embedded in the
> IPv6 address of a CE. So your statement of "totally decoupled" isn't quite
> accurate.
> >>
> >> Cheers,
> >> Wojciech.
> >>
> >>
> >> Best Regards,
> >> Qi
> >>
> >>
> [I-D.ietf-softwire-map] solution.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Cheers,
> >>> Wojciech.
> >>>
> >>>

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 6 Mar 2014 20:06:53 +0000

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
draft. Besides, please correct me if I am wrong, I remember the WG decision
is not to explicitly defining 1:1 in the MAP-E base spec. If the WG wants to
work on 1:1 MAP, it will be on a separate draft.

http://www.ietf.org/proceedings/86/minutes/minutes-86-softwire #25

Date:  Thursday, March 6, 2014 at 6:27 PM

> aggregate rules. This also gives the option of direct meshed IPv4 connectivity
> between subscribers."
> 
>>>> <http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-07#ref-I-D.ietf-so
>>>> ftwire-map> ] provides a suitable solution.
>>>>  
>>>> <http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-07#ref-I-D.ietf-so
>>>> ftwire-map> ] solution.
>>>> 
>>>> Cheers,
>>>> Wojciech.
>>>> 
>>>>

---

From: Tom Taylor <[email-masked]>
Date: Thu, 06 Mar 2014 15:09:57 -0500

"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:
>...

---

From: Qiong <[email-masked]>
Date: Fri, 7 Mar 2014 10:05:53 +0800

Hi Tom,

I also prefer to compare with these solutions in a separate draft.

Best wishes
Qiong

Open source code:

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 7 Mar 2014 09:04:42 +0100

On 6 March 2014 21:06, Lee, Yiu <[email-masked]> wrote:

> 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 draft. Besides, please correct me if I am wrong, I remember the
> WG decision is not to explicitly defining 1:1 in the MAP-E base spec. If
> the WG wants to work on 1:1 MAP, it will be on a separate draft.
>

Two responses:
1. Given your statement above, and in view of the other text in the lw46
section that compares lw46 to DS-lite, I would propose that actually all
text that compares lw46 to other solutions  text be removed. In particular
the following full paragraph should be removed (which is comparative to
DS-lite and MAP).

"By relocating
   the NAPT functionality from the centralized AFTR to the distributed
   B4s, a number of benefits can be realized:

   o  NAPT44 functionality is already widely supported and used in
      today's CPE devices.  Lw4o6 uses this to provide private<->public
      NAPT44, meaning that the service provider does not need a
      centralized NAT44 function.

   o  The amount of state that must be maintained centrally in the AFTR
      can be reduced from per-flow to per-subscriber.  This reduces the
      amount of resources (memory and processing power) necessary in the
      AFTR.

   o  The reduction of maintained state results in a greatly reduced
      logging overhead on the service provider.

   Operator's IPv6 and IPv4 addressing architectures remain independent
   of each other.  Therefore, flexible IPv4/IPv6 addressing schemes can
   be deployed."

2. 1:1 was and still is an intrinsic part of MAP. We certainly never
arrived at consensus that it be "removed" (nor do the above minutes reflect
such consensus) - we did move the text into the appendix. An offer made
long way back to make the lw46 draft, when based on the MAP algorithm be
the draft that describes the "1:1 specialized form of MAP-E" was previously
suggested. By all accounts the lw46 authors did not appear to consent to
this, but perhaps this is still something to pursue.

---

From: Tom Taylor <[email-masked]>
Date: Fri, 07 Mar 2014 07:30:55 -0500

>     of each other.  Therefore, flexible IPv4/IPv6 addressing schemes can

[PTT] Seems reasonable.
...