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

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