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

Wojciech Dec <wdec.ietf@gmail.com> Mon, 03 March 2014 14:20 UTC

Return-Path: <wdec.ietf@gmail.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCE01A00F5 for <softwires@ietfa.amsl.com>; Mon, 3 Mar 2014 06:20:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCCy_f9LZSAW for <softwires@ietfa.amsl.com>; Mon, 3 Mar 2014 06:20:23 -0800 (PST)
Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 61C491A0149 for <softwires@ietf.org>; Mon, 3 Mar 2014 06:20:23 -0800 (PST)
Received: by mail-pd0-f181.google.com with SMTP id p10so3751429pdj.40 for <softwires@ietf.org>; Mon, 03 Mar 2014 06:20:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GilbC10fnytePiSKeAcGV5uIgsOaOtrA+fwK2wPYEsE=; b=CEHnaGj49Q5rLxcutIENpKdagERR27UdfYCIp3/QlXMdiWGCKfYZQ5PSpTUmIzbaQx sqsbHOYZx9dg15mmYOsJeVXQxHMGRHd1HoLy0G+sqnmQrCiTKAOoHXLC4YQzuSa+3y5d taIq6ZT+uOl+Mqq80nwNPgEQJlk7E3UE/K0zcuxNWFQlemoezFXYEmOSpzBFQx6ZwQeN +EM2Mv13xhhZDciN2gpySpOcn+KysHxMLi95R7rGRJyBVV73U4/a2cFTxv4rnNIbIFth gxXnmdiNOZyK46for4gR39P06HritZq97nmu2dPMoQ7mhTI+7MvnsHOiD3CMzZpLNEtP nVkA==
MIME-Version: 1.0
X-Received: by 10.68.105.36 with SMTP id gj4mr8106047pbb.64.1393856420491; Mon, 03 Mar 2014 06:20:20 -0800 (PST)
Received: by 10.70.1.70 with HTTP; Mon, 3 Mar 2014 06:20:20 -0800 (PST)
In-Reply-To: <CF3A3F56.3B435%yiu_lee@cable.comcast.com>
References: <20140211075445.17615.61208.idtracker@ietfa.amsl.com> <FD878467-904B-4441-95B4-11D4461A612E@employees.org> <CF237FDE.AACEB%ian.farrer@telekom.de> <CAFFjW4jOBfvnqCV4UH8qt0HA5zZ-35f+q5ZepzjnwGX5_Oj9Gg@mail.gmail.com> <8A1B81989BCFAE44A22B2B86BF2B76318A2CDB8ED2@HE111643.EMEA1.CDS.T-INTERNAL.COM> <CAFFjW4iP2KqNJFtJPr5rp0tzRwM5TPjaqiSP5r13JqbX46ao7w@mail.gmail.com> <CD1D4FF6-9509-43B4-AFC4-4F1AF99D0C4D@gmx.com> <CAFFjW4ibkj_xpTuXrbYjxkdxD=+qNzapCGPHJwXsZ-k0ZvGg-g@mail.gmail.com> <CF335888.AE89D%ian.farrer@telekom.de> <CAFFjW4hv5WBiqyw9jM+ZoLMGR5k49pjKXG0epnhrsOGoBBKMYA@mail.gmail.com> <CAFFjW4gyvcBTBDjE8nzGbPz8BcHUasHizzzry0cRF+J2T82uSQ@mail.gmail.com> <CF3A3F56.3B435%yiu_lee@cable.comcast.com>
Date: Mon, 03 Mar 2014 15:20:20 +0100
Message-ID: <CAFFjW4j-R03WJdUe5Zb9Q2yuCMBtCOtO490NRjhaWMQ+d3a1xQ@mail.gmail.com>
From: Wojciech Dec <wdec.ietf@gmail.com>
To: "Lee, Yiu" <Yiu_Lee@cable.comcast.com>
Content-Type: multipart/alternative; boundary="047d7b66f01dcfb57204f3b47c8c"
Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/0r89A1JpLrxVp3VdeJW-_H0ICSA
Cc: Softwires-wg <softwires@ietf.org>
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Mar 2014 14:20:32 -0000

It done by having 1 rule for N CEs, i.e. route aggregation vs host routes


On 3 March 2014 15:19, Lee, Yiu <Yiu_Lee@cable.comcast.com> wrote:

> Sorry for my ignorance. How MAP-E optimizes states In hub-and-spoke mode
> compared to lw4o6?
>
> From: Wojciech Dec <wdec.ietf@gmail.com>
> Date: Monday, March 3, 2014 at 1:47 PM
> To: "ian.farrer@telekom.de" <ian.farrer@telekom.de>
>
> Cc: Softwires-wg <softwires@ietf.org>
> Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt
>
> Hi Ian,
>
> following up with some proposed text re relation to MAP
>
>
>> On 26 February 2014 10:31, <ian.farrer@telekom.de> wrote:
>>
>>> Hi Woj,
>>>
>>> I've been out of the office for a couple of days, so sorry for the be
>>> late reply.
>>>
>>> Please see inline.
>>>
>>> Cheers,
>>> Ian
>>>
>>> From: Wojciech Dec <wdec.ietf@gmail.com>
>>> Date: Wednesday, 19 February 2014 09:34
>>> To: Ian Farrer <ianfarrer@gmx.com>
>>> Cc: Softwires-wg <softwires@ietf.org>
>>> Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt
>>>
>>> Hi Ian,
>>>
>>> Just to be clear: I'm ok with lw46 defining a specific functional mode
>>> as I believe it does in this draft, also leaving "as-is" the DHCP part of
>>> it (i.e. it's a capability that can be signalled using the lw46 container,
>>> etc).
>>>
>>> [ian] It would help if you could propose text for what you would like to
>>> see. The inline discussion has become quite protracted.
>>>
>>
>> I'll follow up on that...
>>
>>
>>>
>>>
> Here I'm pointing out that IPinIP dataplane + ICMP wise there should be no
> difference between lw46 and MAP-E, and in effect a single BR or lw46 AFTR
> implementation can be made of these.
>
> 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.
>
>
>
>