In the current text, there is no comparison term such as “more optimizing” or “reducing”. These terms are used to comparing two solutions. I echo Qiong and Qi in their replies: this is not necessary to compare two solutions. Similarly, I also think it is not necessary to mention lw4o6 in the MAP-E draft. Besides, please correct me if I am wrong, I remember the WG decision is not to explicitly defining 1:1 in the MAP-E base spec. If the WG wants to work on 1:1 MAP, it will be on a separate draft.
http://www.ietf.org/proceedings/86/minutes/minutes-86-softwire #25 From: Wojciech Dec <[email protected]> Date: Thursday, March 6, 2014 at 6:27 PM To: "Yiu L. LEE" <[email protected]> Cc: Softwires-wg WG <[email protected]> Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt On 6 March 2014 15:41, Lee, Yiu <[email protected]> wrote: > I still have problem to include text to compare two methods. Why not remove > the whole sentence as Ole stated in his email? You appear not to have had a problem with the current text. What is the problem with the new one? Also note that MAP-E would get also a suitable pointer to the lw46 draft concerning the 1:1 mode. > > Yiu > > From: Ian Farrer <[email protected]> > Date: Thursday, March 6, 2014 at 11:27 AM > To: Wojciech Dec <[email protected]> > Cc: Softwires-wg WG <[email protected]> > > Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt > > 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 >>>> <http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-07#ref-I-D.ietf-so >>>> ftwire-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-so >>>> ftwire-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 >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
