On Mon, Mar 3, 2014 at 11:37 PM, 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. > > I couldn't understand your point. Address mapping flexibility is independent from whether it is in H&S operation or not. --satoru > 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
