On Tue, Mar 4, 2014 at 12:13 AM, Qi Sun <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >> >> >> >> >> On 3 March 2014 15:20, Wojciech Dec <[email protected]> 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 <[email protected]> wrote: >>> >>>> Sorry for my ignorance. How MAP-E optimizes states In hub-and-spoke >>>> mode compared to lw4o6? >>>> >>>> From: Wojciech Dec <[email protected]> >>>> Date: Monday, March 3, 2014 at 1:47 PM >>>> To: "[email protected]" <[email protected]> >>>> >>>> Cc: Softwires-wg <[email protected]> >>>> 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, <[email protected]> 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 <[email protected]> >>>>>> Date: Wednesday, 19 February 2014 09:34 >>>>>> To: Ian Farrer <[email protected]> >>>>>> Cc: Softwires-wg <[email protected]> >>>>>> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires >> >> >> > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires > > > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
