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
