Would you be more comfortable with "reducing"?
On 6 March 2014 16:17, Yuchi Chen <[email protected]> wrote: > Hi Ian, > > If we decided to keep the text, I suggest to remove the "offers a means > for optimizing" part. It may not be a good idea to teach operators what > should be "optimize". > > What I mostly suggest is to remove the entire text. > > Best regards! > -------------- > Yuchi Chen > > On 2014-03-06, 19:27, "Ian Farrer" <[email protected]> wrote: > >Here’s the text that Woj mentioned: > > > >"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 optimizing 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." > > > >My position on this is that I am fine with the text above, I’m happy with > a wordsmithed version that is mutually agreeable and I am also fine with > the text being removed altogether. > > > >Whichever one can get us past this point is the right answer. > > > >Ian > > > >On 6 Mar 2014, at 10:28, Wojciech Dec <[email protected]> wrote: > > > >> Qi, > >> > >> > >> On 5 March 2014 17:17, Qi Sun <[email protected]> wrote: > >> > >> Woj, > >> > >> I don't think map is more optimized than lw4over6 when IPv4 and IPv6 > are totally decoupled (which is lw4over6 designed to deal with). I would > prefer to follow Ole's suggestion at this point, i.e. remove this text. > >> > >> The point is that such state optimization is possible, using v4-v6 > address mapping, which is a characteristic of MAP and mesh mode which the > current text refers to is its by product. > >> > >> We have with Ian a new adequate sentence which fixes things, and I'll > let Ian post it. It is important to have such text for at least the > following reason: > >> The solutions have much in common; utilize the same MAP PSID algorithm > (although with different defaults), encap, etc. They're not thus > orthogonal, and while some may wish to implement them independently, which > is possible there is enough commonality to warrant to "pointer text". > >> > >> A side note > >> In both lw4over6 and MAP the IPv4 address+PSID are embedded in the > IPv6 address of a CE. So your statement of "totally decoupled" isn't quite > accurate. > >> > >> Cheers, > >> Wojciech. > >> > >> > >> Best Regards, > >> Qi > >> > >> > >> On 2014-3-3, at 下午1:47, Wojciech Dec wrote: > >> > >>> > >>> 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] 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] 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
