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

On Tue, Mar 4, 2014 at 12:13 AM, Qi Sun <sunqi.csnet.thu@gmail.com> 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

>
> 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 <http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-07#ref-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 <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.
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>> _______________________________________________
>> 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
>
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>
>