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... )
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] > 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] 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 >> [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
