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.
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-softw > ire-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-softw > ire-map> ] solution. > > Cheers, > Wojciech. > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
