On 3 March 2014 17:57, Lee, Yiu <[email protected]> wrote: > How MAP-E aggregates CPE for N CEs in hub-and-spoke? When implementing MAP > in hub-and-spoke, cpe/ce v4 information is in the br. Each ce will have an > entry in the br. This is the same number of states lw4o6 will maintain. Am > I missing something? I support to keep the original text in the draft. >
You appear to be confusing the relation between hub&spoke and number of BR rules. In MAP optimized + hub&spoke mode the following applies: - Each CE has just 1 DMR (aka default rule, aka default route). Mesh mode is not active in this case - Each BR has just 1 forwarding rule for the N CE's that are part of its domain. That changes to N rules in the 1:1 case. > > From: Wojciech Dec <[email protected]> > Date: Monday, March 3, 2014 at 2:20 PM > To: "Yiu L. LEE" <[email protected]> > Cc: "[email protected]" <[email protected]>, Softwires-wg < > [email protected]> > > Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt > > It done by having 1 rule for N CEs, i.e. route aggregation vs host routes > > > 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
