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

On 3 March 2014 17:57, Lee, Yiu <Yiu_Lee@cable.comcast.com> 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.
>

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: Wojciech Dec <wdec.ietf@gmail.com>
> Date: Monday, March 3, 2014 at 2:20 PM
> To: "Yiu L. LEE" <yiu_lee@cable.comcast.com>
> Cc: "ian.farrer@telekom.de" <ian.farrer@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_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
>
>