Hi Woj, On 2014-3-12, at 下午5:50, Wojciech Dec wrote: > > On 12 March 2014 10:32, <[email protected]> wrote: > Hi Woj, > > Just for context, the ‘complete independence’ wording was taken from the > map-dhcp draft (section 3). The hope was that this wouldn’t be a contentious > phrase because of that. > > Well, but given that it's not technically accurate it doesn't really matter > where it's taken from. > Can't really say more about this other than what I replied to previously. If > you really want some text in there, I'd be ok with text like: "Both solutions > allow for IPv6 prefix independence, i.e.the IPv6 prefix does not embed an > IPv4 address and/or port set" although it doesn't really add anything of > major relevance, > > I think we'd be best served without re-hashing the lengthy discussion we had > at the meeting or having another long email thread here on a few words and > delay the lw46 draft further, i.e. let's stay with the chairs' conclusion on > the matter.
I also hope to end this discussion asap. As the minutes stated: " Summary: 3. Cross-reference: As chair I'll decide that we keep the text with the proposed changes. MAP does aggregation and mesh. " The text we proposed includes the two points, and takes words from map-dhcp document (which is technically accurate as the prefix embedding thing does not happen in lw4over6). Best Regards, Qi > > > Cheers, > Ian > > From: Wojciech Dec <[email protected]> > Date: Wednesday, 12 March 2014 10:25 > To: Qi Sun <[email protected]> > Cc: Softwires-wg WG <[email protected]> > Subject: Re: [Softwires] Proposed text that describes lw4o6 and map-e > > Hi Qi, > > thanks, but I'd rather stick with the text that we proposed and (lengthily) > discussed at the meeting, i.e.: > > "Lightweight 4over6 provides a solution for a hub-and-spoke softwire > architecture only, where the lwAFTR maintains (softwire) state for each > subscriber. [I-D.ietf-softwire-map] offers > a means for reducing the amount of such state by using algorithmic IPv4 to > IPv6 address mappings to create aggregate rules. This also gives the option > of direct meshed IPv4 connectivity between subscribers." > > Note: Your text is different to the above, and claims "complete > independence" which is not accurate in view of the fact that lw46 DOES embed > the IPv4 address in the IPv6 address. In terms of embedding stuff in the > "prefix part" (i.e. the top /64), both solutions allow "complete prefix > independence", so that's a null point. > > Regards, > Wojciech. > > > > On 12 March 2014 08:51, Qi Sun <[email protected]> wrote: > > Hi all, > > According to the discussion last Friday, there should be some text describing > the characteristics of lw4o6 and map-e with cross-referece, and the text > should be the same (or almost the same). > > The two points that are requested to be in the text: > * MAP-E achieves aggregated rules > * MAP-E does mesh > > Here is the proposal: > > In lw4o6 draft, section of Introduction: > Lightweight 4over6 provides a solution with complete independence of IPv4 > and IPv6 addressing (i.e., the IPv6 prefix does not embed an IPv4 address > and/or port set). This is accomplished by maintaining state for each > softwire (per-subscriber state) in the lwAFTR and using a hub-and-spoke > architecture whereby all traffic traverse the lwAFTR. [I-D.ietf-softwire- > map] offers a means for reducing the amount of such state by using > algorithmic IPv4 to IPv6 address mappings to create aggregate rules. This > also gives the option of direct, meshed IPv4 connectivity between > subscribers. > > In MAP-E draft, section of Introduction: > MAP-E offers a means for reducing the amount state held in the BR by > using algorithmic IPv4 to IPv6 address mappings to create aggregate rules. > This also gives the option of direct, meshed IPv4 connectivity between > subscribers. Lightweight 4over6 [I-D.ietf-softwire-lw4over6] provides a > solution with complete independence of IPv4 and IPv6 addressing > (i.e., the IPv6 prefix does not embed an IPv4 address and/or port set). This > is > accomplished by maintaining state for each softwire (per-subscriber state) > in the lwAFTR and using a hub-and-spoke architecture whereby all traffic > traverse the lwAFTR. > > The above text has been agreed by the lw4over6 co-authors. > @Woj, could you please see if the the proposal resolves your concern? Thanks! > > > Best Regards, > Qi > > > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
