Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt

["Lee, Yiu" <[e-mail]>]

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 <[e-mail]>
Date:  Thursday, March 6, 2014 at 6:27 PM
To:  "Yiu L. LEE" <[e-mail]>
Cc:  Softwires-wg WG <[e-mail]>
Subject:  Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt




On 6 March 2014 15:41, Lee, Yiu <[e-mail]> 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 <[e-mail]>
> Date: Thursday, March 6, 2014 at 11:27 AM
> To: Wojciech Dec <[e-mail]>
> Cc: Softwires-wg WG <[e-mail]>
> 
> 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 <[e-mail]> wrote:
> 
>> Qi,
>> 
>> 
>> On 5 March 2014 17:17, Qi Sun <[e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/softwires
>>> 
>> 
>> _______________________________________________
>> Softwires mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires
> 
> 
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires
>