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

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:

> 
> 
> 
> On 3 March 2014 15:37, Ian Farrer <ianfarrer@gmx.com> 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.
> 
> 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 
> 
> connectivity between subscribers, are features of the [I-D.ietf-softwire-map] solution.
> 
> 
> -Wojciech.
>  
> 
> Cheers,
> Ian
> 
> On 3 Mar 2014, at 14:22, Wojciech Dec <wdec.ietf@gmail.com> wrote:
> 
>> 
>> 
>> 
>> On 3 March 2014 15:20, Wojciech Dec <wdec.ietf@gmail.com> wrote:
>> 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.
>> 
>> 
>> On 3 March 2014 15:19, Lee, Yiu <Yiu_Lee@cable.comcast.com> wrote:
>> Sorry for my ignorance. How MAP-E optimizes states In hub-and-spoke mode compared to lw4o6? 
>> 
>> From: Wojciech Dec <wdec.ietf@gmail.com>
>> Date: Monday, March 3, 2014 at 1:47 PM
>> To: "ian.farrer@telekom.de" <ian.farrer@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.farrer@telekom.de> 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 <wdec.ietf@gmail.com>
>> Date: Wednesday, 19 February 2014 09:34
>> To: Ian Farrer <ianfarrer@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. 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] 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] solution.
>> 
>> 
>> 
>> 
>> Cheers,
>> Wojciech.
>> 
>>  
>> 
>> 
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
> 
> 
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires