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

On 6 March 2014 21:06, Lee, Yiu <Yiu_Lee@cable.comcast.com> wrote:

> 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.
>

Two responses:
1. Given your statement above, and in view of the other text in the lw46
section that compares lw46 to DS-lite, I would propose that actually all
text that compares lw46 to other solutions  text be removed. In particular
the following full paragraph should be removed (which is comparative to
DS-lite and MAP).

"By relocating
   the NAPT functionality from the centralized AFTR to the distributed
   B4s, a number of benefits can be realized:

   o  NAPT44 functionality is already widely supported and used in
      today's CPE devices.  Lw4o6 uses this to provide private<->public
      NAPT44, meaning that the service provider does not need a
      centralized NAT44 function.

   o  The amount of state that must be maintained centrally in the AFTR
      can be reduced from per-flow to per-subscriber.  This reduces the
      amount of resources (memory and processing power) necessary in the
      AFTR.

   o  The reduction of maintained state results in a greatly reduced
      logging overhead on the service provider.

   Operator's IPv6 and IPv4 addressing architectures remain independent
   of each other.  Therefore, flexible IPv4/IPv6 addressing schemes can
   be deployed."

2. 1:1 was and still is an intrinsic part of MAP. We certainly never
arrived at consensus that it be "removed" (nor do the above minutes reflect
such consensus) - we did move the text into the appendix. An offer made
long way back to make the lw46 draft, when based on the MAP algorithm be
the draft that describes the "1:1 specialized form of MAP-E" was previously
suggested. By all accounts the lw46 authors did not appear to consent to
this, but perhaps this is still something to pursue.

>
> http://www.ietf.org/proceedings/86/minutes/minutes-86-softwire #25
>

>
>
> From: Wojciech Dec <wdec.ietf@gmail.com>
> Date: Thursday, March 6, 2014 at 6:27 PM
> To: "Yiu L. LEE" <yiu_lee@cable.comcast.com>
>
> Cc: Softwires-wg WG <softwires@ietf.org>
> Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt
>
>
>
>
> On 6 March 2014 15:41, Lee, Yiu <Yiu_Lee@cable.comcast.com> 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 <ianfarrer@gmx.com>
>> Date: Thursday, March 6, 2014 at 11:27 AM
>> To: Wojciech Dec <wdec.ietf@gmail.com>
>> Cc: Softwires-wg WG <softwires@ietf.org>
>>
>> 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 <wdec.ietf@gmail.com> wrote:
>>
>> Qi,
>>
>>
>> On 5 March 2014 17:17, Qi Sun <sunqi.csnet.thu@gmail.com> 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-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 <http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-07#ref-I-D.ietf-softwire-map>] solution.
>>>
>>> Cheers,
>>>
>>> Wojciech.
>>>
>>>
>>>
>>> _______________________________________________
>>> Softwires mailing list
>>> Softwires@ietf.org
>>> https://www.ietf.org/mailman/listinfo/softwires
>>>
>>>
>>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>>
>>
>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>>
>>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>
>