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

On Mon, Mar 3, 2014 at 11:37 PM, 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.
>
>
I couldn't understand your point. Address mapping flexibility is
independent from whether it is in H&S operation or not.
--satoru

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