Re: [Softwires] WGLC on draft-ietf-softwire-unified-cpe-03

Ian Farrer <ianfarrer@gmx.com> Tue, 19 April 2016 20:25 UTC

Return-Path: <ianfarrer@gmx.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C633A12DF4F; Tue, 19 Apr 2016 13:25:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Uaj74EaaAyOz; Tue, 19 Apr 2016 13:25:42 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD08612DEB5; Tue, 19 Apr 2016 13:25:41 -0700 (PDT)
Received: from [10.1.125.2] ([46.189.67.121]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M6RiN-1bgrc429eN-00yRyg; Tue, 19 Apr 2016 22:25:27 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Ian Farrer <ianfarrer@gmx.com>
In-Reply-To: <2D252834-F869-462F-AF43-35F1E90B347D@employees.org>
Date: Tue, 19 Apr 2016 22:25:25 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <00231DD3-A8B1-4688-8601-9CFFBA6830DD@gmx.com>
References: <303647F4-AC89-485A-A13A-E34D91593206@tsinghua.edu.cn> <2D252834-F869-462F-AF43-35F1E90B347D@employees.org>
To: otroan@employees.org
X-Mailer: Apple Mail (2.2104)
X-Provags-ID: V03:K0:hXbFJ7EeXPZKJnc2f7r/XRHu606Isb44Q2pALs2nzJ/7Sf4SUA1 R0KDNVawLc6Kp6yTwXY19rYyxAbdIh9MB8MEXaA958aJTGB5SUgbKMZnG3+SKr/pIeqohHa Ej64rvI5pG0l52wUCZREFk+d+OCqEY+FnSapBfaRwkKnKOH/1QMww4B+6NiORUpPKJ7G2sJ wLA7MFpOFA2ccbLRN8Zfw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:+S10dQQOFAM=:96mlidYGTMRug0np7GYbBg mI6cLiGY4XCF3VIIpTp1qeIvLejr6XPdKOViq1UQxXXELvC3q67a6zbDyjsZoXt8v1OeA2NhV RwBwINukuoGeCTHfVe9iVXnmRwspPXZgFrWrljDP0MyWeXDBxEQpg30FC2tXUV3EBZpxppywW Wm4vmt/AXdLxbHZNwJvwmtkJZp+s26dCEs5eyn7tbnEJYiNYpM385G8x/NLMgmD1kH+jekIvX +cgZXNe/ZiF5pkj3PqhDJtYwj6ZkZWV7D6SkGq7F1V9TuL6/xhrpDlBJ5WFRSS8FgAYpQ/HVQ xYMmDMcibO7WaxzdFHOBdkwJGURVgthkH1PfhYSIR09zPXkrBT5N+8cBshuSPNSE29utQDpvY 1uB1lRenUr1CZHa1h43yA/kmAlWPcV7t3Az2KCXMX2NoXf20MgU5LhKAYXi9twkynirngcEE9 EFOdhUmSxNEdg/Nq0nCvQD3zuzXwr4Z8+W7VGql0VG0WnbikCIuo8HmCv6Nh+9QmemH/XwoPy 2e6OvwOlkogGyvtIpwpam21n1urs/JZ/7ZcyYv02xAMc6qUbOlD8DVDi0wDgkXwRpIXHHV7qj pGDTRASkQrB4ciK0bFK/wjA6ea1guciBykaq0/s5hiunLIL4GTU6Rs7cimolSSczBqaOR0OwF oSNhuC//zk+obVMw+BdhhWq9Sqz2mY3sZcR8Ce0O05kbL1ljmTAxpy3/AyVQn2ocLL52Izvq4 C0lOhREY8mju8MHXvBbhiqR429HpP9NZs7X5bxjhixTKhKDniv0wtpxmUFvYX2Mwr5JJzhfdL Erlnb4I
Archived-At: <http://mailarchive.ietf.org/arch/msg/softwires/KSuMmrs0h0qqWhjpxk0EXcYmGos>
Cc: Softwires WG <softwires@ietf.org>, "softwire-chairs@ietf.org" <softwire-chairs@ietf.org>, Yong Cui <cuiyong@tsinghua.edu.cn>
Subject: Re: [Softwires] WGLC on draft-ietf-softwire-unified-cpe-03
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 19 Apr 2016 20:25:45 -0000

Hi Ole,

Thanks for the comments. Please see inline.

Cheers,
Ian

> On 15 Apr 2016, at 10:41, otroan@employees.org wrote:
> 
> Here are my comments from a quick glance. Apologies for being late.
> 
> Thanks for simplifying this document.
> A much easier and less contentious read now.
> 
> I think it needs a little bit more detail and explanation before advancing though.
> 
> The document is lacking some detail. It mentions "DHCPv6 Offer", which in 3315 terminology I'm not sure what is.
> In a 4-way DHCPv6 exchange, would the expectation be something like:
> 
> -> SOLICIT:  ORO includes MAP-E, LW46, and DS-lite and Priority option request.
> <- ADVERTISE : includes priority option, with MAP-E, DS-lite and LW46 data objects (server might have reserved address at this point)
> -> REQUEST: client only request the mechanism at the top of the list
> <- REPLY: server assigns the addresses to client, and can free up resources reserved for the other mechanisms.

[if - Good catch on the ‘offer’. Will update.

For the proposed message flow and corresponding server side actions, there is no dynamic on demand assignment of DHCP managed resources being made for any of these mechanisms, with the exception of DHCPv4oDHCPv6 provisioning. DS-lite only dynamically allocates any resources used for CGN44 at the AFTR when a client 4in6 outgoing request is made. MAP & lw4o6 using RFC7598 both require the DHCP server to be pre-configured and there is no pool based allocation that resources are taken from or returned to.

DHCPv4oDHCPv6 can make dynamic pool allocations, but unless the client implemented this and used it for its provisioning, then a lease would never be made.]

> 
> If I was an operator that had a fixed allocation of address 1.1.1.1:1000-2000 to a given customer. Would I then put the same IPv4 address for each of the mechanisms in the ADVERTISE?

[if - That’s really a deployment choice. Certainly, there’s no reason why the provisioning mechanism couldn’t supply either the same or different addressing allocations to the client, but from a BR functionality and routing perspective it’s unlikely that you would be able to do this - the BR would have to be running at least two BR mechanisms in parallel and have a way of identifying which particular mechanism a client was using. Could be hard for ingress traffic on a MAP-E/T BR for example.

We can add some text discussing this point.]

> 
> Do you need to say anything about how to deal with clients that do not support the priority option?

[if - This would require server side logic to evaluate the softwire option codes in the ORO supplied by the client and provision a single mechanism based on server side policy. However, as one of the main points of writing this draft in the first place is to avoid having to do this (for complexity and scalability reasons), I would suggest that the text could describe this with the drawbacks and without adding any requirements to implement this functionality.]

> 
> Cheers,
> Ole
> 
> 
> 
> 
>> On 22 Mar 2016, at 07:55, Yong Cui <cuiyong@tsinghua.edu.cn> wrote:
>> 
>> Hi folks,
>> 
>> The authors of draft-ietf-softwire-unified-cpe-03 believe this document is ready for advancement.
>> We would like to issue a working group last call starting from today to April 5th.
>> 
>> Please send your substantial comments to the list during the last call. You are also welcome to send your editorial comments directly to the authors.
>> 
>> Thanks for reviewing the draft.
>> 
>> 
>> Yong Cui, Suresh Krishnan and Ian Farrer
>> 
>> 
>> 
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>