Re: [mif-arch-dt] Strawman solution proposals for DHCPv6 and RA support for multiple provisioning domains

Dmitry Anipko <Dmitry.Anipko@microsoft.com> Tue, 07 January 2014 03:04 UTC

Return-Path: <Dmitry.Anipko@microsoft.com>
X-Original-To: mif-arch-dt@ietfa.amsl.com
Delivered-To: mif-arch-dt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D601ADF5A for <mif-arch-dt@ietfa.amsl.com>; Mon, 6 Jan 2014 19:04:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 Oe5nygHyTIlJ for <mif-arch-dt@ietfa.amsl.com>; Mon, 6 Jan 2014 19:04:14 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 003DB1ADF35 for <mif-arch-dt@ietf.org>; Mon, 6 Jan 2014 19:04:13 -0800 (PST)
Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB080.namprd03.prod.outlook.com (10.255.175.156) with Microsoft SMTP Server (TLS) id 15.0.847.13; Tue, 7 Jan 2014 03:04:04 +0000
Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.107]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.107]) with mapi id 15.00.0847.008; Tue, 7 Jan 2014 03:04:03 +0000
From: Dmitry Anipko <Dmitry.Anipko@microsoft.com>
To: Tim Chown <tjc@ecs.soton.ac.uk>, Ted Lemon <Ted.Lemon@nominum.com>
Thread-Topic: [mif-arch-dt] Strawman solution proposals for DHCPv6 and RA support for multiple provisioning domains
Thread-Index: AQHO0Al1EuDFRbK3sEiC7iRTvO04C5oURpXpgAEqagCAE0vn0YAI7uIAgAA4eoCAAAFeAIAACtIAgAKtmACARB4+QA==
Date: Tue, 07 Jan 2014 03:04:03 +0000
Message-ID: <7fbfae5a491e4540900b935c26ef8676@SN2PR03MB077.namprd03.prod.outlook.com>
References: <5267F29C.3010304@ericsson.com> <0010ca0ba1f44fe2a1b8fa5f110a00c0@SN2PR03MB077.namprd03.prod.outlook.com>, <41845B5F-8694-4368-B2F6-BA3BA0CFDD91@gmail.com> <ee10ff9826854918aebf0565c93ce5a9@SN2PR03MB077.namprd03.prod.outlook.com> <E07F8EDD-6BA5-4B7D-B307-C819B6AC2053@gmail.com> <6AC3097B-C63D-4DC6-80BE-29FEFE355D40@nominum.com> <E30067C3-A44D-478A-9D78-CA2D078A8A76@viagenie.ca> <1CC2DB29-E87A-4F86-BED7-8A1750B22720@nominum.com> <19CBC9C7-1609-44D0-AA39-EC4EF0348B6B@ecs.soton.ac.uk> <EMEW3|7933263be2055c213c80f3b19e4c16f0pANECh03tjc|ecs.soton.ac.uk|19CBC9C7-1609-44D0-AA39-EC4EF0348B6B@ecs.soton.ac.uk>
In-Reply-To: <EMEW3|7933263be2055c213c80f3b19e4c16f0pANECh03tjc|ecs.soton.ac.uk|19CBC9C7-1609-44D0-AA39-EC4EF0348B6B@ecs.soton.ac.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e0:ed43::2]
x-forefront-prvs: 008421A8FF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(13464003)(24454002)(199002)(189002)(377454003)(51704005)(83322001)(54316002)(19580405001)(19580395003)(83072002)(56816005)(85852003)(90146001)(85306002)(76576001)(77096001)(74366001)(76796001)(76786001)(69226001)(79102001)(80022001)(65816001)(63696002)(77982001)(59766001)(56776001)(81542001)(87936001)(2656002)(74662001)(31966008)(80976001)(76482001)(47446002)(74502001)(87266001)(33646001)(74706001)(81342001)(74876001)(81816001)(49866001)(47736001)(4396001)(51856001)(50986001)(47976001)(53806001)(561944002)(54356001)(74316001)(81686001)(46102001)(3826001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB080; H:SN2PR03MB077.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ed43::2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: Marc Blanchet <marc.blanchet@viagenie.ca>, Jouni Korhonen <jouni.nospam@gmail.com>, "mif-arch-dt@ietf.org" <mif-arch-dt@ietf.org>, Suresh Krishnan <suresh.krishnan@ericsson.com>
Subject: Re: [mif-arch-dt] Strawman solution proposals for DHCPv6 and RA support for multiple provisioning domains
X-BeenThere: mif-arch-dt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: MIF Architecture Design Team mailing list <mif-arch-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif-arch-dt>, <mailto:mif-arch-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif-arch-dt/>
List-Post: <mailto:mif-arch-dt@ietf.org>
List-Help: <mailto:mif-arch-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif-arch-dt>, <mailto:mif-arch-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jan 2014 03:04:16 -0000

Reviving the discussion after holidays, since it doesn't seem it converged on something.

>> We seem to commonly refer to a user selecting an SSID and a PVD-ID following implicitly from that; so the PVD-ID is implicitly acquired, and the user may never need to see it.

In some cases this is possible, and the arch draft describes this as a possibility, but it's not the only possibility, and also, in some cases such selection is not possible - if there is more than one PVD on the link (2 ISPs at home).

>> In the case of a mutli-homed IPv6 site with multiple prefixes, from different providers, users on workstations with two IPv6 prefixes don't currently make selections,

To me it doesn't seem that explicit choice by end user is precluded, though I agree that it probably would not be common. That said, even when the end user can't or doesn't want to choose, there may still be a need to show to the user "descriptive information" about the PVD, which e.g. is currently used to access the Internet. 

>> Perhaps we need something in the draft to discuss the possible 'consumers' of PVDs?

Do you mean to the arch draft? If yes, if you send any rough thoughts on that, I'm happy to include in the next revision if that helps us move forward in making the scenario descriptions more specific and hence the requirements for IDs more specific.

-----Original Message-----
From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] 
Sent: Sunday, November 24, 2013 6:11 AM
To: Ted Lemon
Cc: Marc Blanchet; Jouni Korhonen; Dmitry Anipko; mif-arch-dt@ietf.org; Suresh Krishnan
Subject: Re: [mif-arch-dt] Strawman solution proposals for DHCPv6 and RA support for multiple provisioning domains


On 22 Nov 2013, at 21:17, Ted Lemon <Ted.Lemon@nominum.com> wrote:

> On Nov 22, 2013, at 3:38 PM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:
>> But if is a human-readable for end-users, as you seem to assume above, then we enter into the languages, scripts, i18n, normalization and
> 
> This is not that hard, and we shouldn't avoid it.   Of course names need to be human-readable. So encode them in UTF-8.   (I'm oversimplifying, because you still need a unique identifier, and that's likely _not_ the name.)

I think there's many potential scenarios for PVD-IDs, and to what or whom they may or may not be exposed to or required by, be the 'consumer' users or applications.

We seem to commonly refer to a user selecting an SSID and a PVD-ID following implictly from that; so the PVD-ID is implictly acquired, and the user may never need to see it. The user device may however have multiple interfaces, e.g. WiFi and 3G. I believe that iOS7 runs MPTCP across both wired and wireless interfaces for Siri, which is an interesting example.

Another example is selecting and using a VPN; there is again an implicit PVD-ID associated with the connection when the user initiates the VPN (or the VPN auto connects). We said at IETF88 that certain applications should be configurable to run only if a certain VPN PVD is available.

In the case of a mutli-homed IPv6 site with multiple prefixes, from different providers, users on workstations with two IPv6 prefixes don't currently make selections, rather they rely on address selection or some other policy to be applied.  In this PVD case, an application may again wish to only run if a certain PVD is available, e.g. one prefix is associated with a PVD for some IP TV service, the other prefix is used for general Internet.

The above behaviours don't require users to select PVDs, except where they are already exposed today as SSIDs or VPNs, but applications seem more likely to be able to assert a certain PVD is in place?

Perhaps we need something in the draft to discuss the possible 'consumers' of PVDs?

Tim