Re: [mif] WGLC for draft-ietf-mif-mpvd-id

Ian Farrer <ianfarrer@gmx.com> Tue, 21 July 2015 09:02 UTC

Return-Path: <ianfarrer@gmx.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9F01B2C31 for <mif@ietfa.amsl.com>; Tue, 21 Jul 2015 02:02:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.899
X-Spam-Level:
X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 UdQEWyGK4nsp for <mif@ietfa.amsl.com>; Tue, 21 Jul 2015 02:02:44 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 BDE301B2BDE for <mif@ietf.org>; Tue, 21 Jul 2015 02:02:43 -0700 (PDT)
Received: from dhcp-b16c.meeting.ietf.org ([31.133.177.108]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LsUDg-1Yp6in2HqS-011yqq; Tue, 21 Jul 2015 11:02:41 +0200
Content-Type: multipart/alternative; boundary="Apple-Mail=_1A9A0DF0-AA97-484A-A040-EEC4FA47EC7B"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Ian Farrer <ianfarrer@gmx.com>
In-Reply-To: <55AD3922.8090009@gmail.com>
Date: Tue, 21 Jul 2015 11:02:40 +0200
Message-Id: <69E5A45D-C11A-4383-A4EE-AEF05675E718@gmx.com>
References: <COL125-W4170BE78E2C2F41BC3A6B4B19B0@phx.gbl> <79C18793-758C-421A-A0C6-2F5625F1E17E@gmx.com> <55AD3922.8090009@gmail.com>
To: Jouni Korhonen <jouni.nospam@gmail.com>
X-Mailer: Apple Mail (2.2102)
X-Provags-ID: V03:K0:FpFIUekJ7+J0cKVtsy3BFNV7PDmbsrY9vU2hMTLHpQJbDFq1bTL AL5TeHygfiMTUbgMs2fZw6dPbNEfAQvEi//+pOx8Dznts0THU3Jd0iTYZTSPv52Mlwl1pJC hJWmCAHQD2Mftw/2vtDX3KD0yoWezC1RT10MO9OveJ3dGnwWKYtIYRqWNKZ77DVEwOwS4Al vyX3nbDkcz/1AKgkP67yA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:GSTuAuShzDA=:x84lNsyhVALY9WKgTfobuG eVXB1M/pnzf2uKnUzko6eYHcj4WRQic4pmkzwMB0dRtsOone+V0xbio71kZyAEuUby2fCKO6N 4mS4ntBz2Z5WhMb813x+icNOQlVK97JjGRY/bBwMHJ5R1p+cwkabgLdWaqJqWjJGIHnE9IOK2 N1lPS3hXSj+mV4Ipkb4p3S7XIGXAw8LArjhvBhlXErCjJQPFl00wUPZZJepuzh8p5TluvPylE 5mdQqWHSianuAmyodAMozgJnzD7EiJS/yIUJmrIlD0JFmkJNiIVVrUnaoWuGwu4CZX123yntF qB29Ubtz8cuuLNtgVSwBbGzg6Ljk90IfNeYDk/U9y+ZoTND+FYMKNgx/lFVUJkq+1j/oQ4pcd ipaX7rtr60zSuvUvaMvW66V73NGUIj1pHmFsRRFA08O35vtaAh07EMopJ4yv6WX0Sr3dPq48k 8Mp8BrHobKyXn0RQgXw1yBse8Ta0FrQIaY9u3xyr/RE5CoLBkq2Ledf4OLRHqV4RA4p5JO9r/ HRU0c+muh75Vz7nHRDAr0nes2Ybluva6eB2sBHSik76cC4vjwAgAB1HCzAn7G/9nZuzjzZrqb 7BLR1mscDqlld+CK3wh+N5WeXFe8Rx6DUlZHU6DShXQuHgMIhfD0zGUQzXB897vtFhZGuwaYx C6YG664da5t4RyT5u/RelsUsnAQF91bVA8Dc9bIBTaYt7EMyTqg/U2zNnHskiz5N8CN4=
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/SVHVyyFAP4DOGe96TiVKuCQaX8s>
Cc: "mif@ietf.org" <mif@ietf.org>, Hui Deng <denghui02@hotmail.com>
Subject: Re: [mif] WGLC for draft-ietf-mif-mpvd-id
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mif/>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jul 2015 09:02:46 -0000

Hi Jouni,

The specific things that I think need to be addressed here are:

1, Removing the decision making process for an operator looking to choose the right format to use. This needs to be common across the whole of an operator’s network and so needs to be supported by all devices and advertising/provisioning protocols present and future. Once deployed at any scale, changing this will be non-trivial.

2, At this stage in the development of the PvD architecture, it is very difficult to know how this will need to evolve and be extended in the future, so it is almost impossible to make an informed decision about what the best PvD format to choose is.

So, this is why I think that choosing a single format with a high probability of uniqueness and a small, defined size. But this needs to be combined with extensibility for adding meta-data to take advantage of the capabilities of less constrained devices and advertising protocols so that additional information can be supplied to allow clients / applications / users to make an informed decision about the PvD.

How I would see this working is that the PvD-ID itself would be a single format - e.g. UUID. This must be advertised in all provisioning messages. An additional DHCPv6/PIO option would then be defined that allows an operator to add additional meta-data options which are associated with the PVD-ID according to their needs / the capabilities of the device/protocols etc (i.e. the other PvD-ID formats that have been described in the draft). 

This allows for the mechanism to be extended as needed without the need to change the PvD-ID formats that are in use in existing devices. If you want to extend your PvD architecture so that new devices have new logic for selecting the correct PvD based on new logic, then you can add a new PvD-ID meta-data option linked to an existing PvD-ID without needing to change the underlying PvD architecture or devices that you have deployed.

With the current mechanism as described, to make any changes to your PvD architecture to support new client PvD selection logic requires deploying another PvD format in parallel to the existing one. This is, by the PvD architecture a new PvD, even if the service properties are identical to an existing PvD which you have already deployed. Then, your provisioning protocols need to advertise duplicate configuration for both of the PvDs, even thought that configuration is the same, with the exception of the PvD-ID.

So, the short answer to your question is: Single PvD-ID format (I like UUID) + extensible associated meta-data.

Cheers,
Ian


> On 20 Jul 2015, at 20:08, Jouni Korhonen <jouni.nospam@gmail.com> wrote:
> 
> Ian,
> 
> So would UUID be adequate PVD-ID format as suggested below?
> 
> What about the additonal information part? Not needed?
> 
> - Jouni
> 
> 
> 7/20/2015, 7:33 AM, Ian Farrer kirjoitti:
>> Hi,
>> 
>> Before this document can proceed, I think that there is still a
>> significant open point. Multiple or single PVD ID formats?
>> 
>> This question has been raised a few times at WG meetings, but there is
>> no reflection in the draft as it stands. This is an excerpt from the
>> IETF91 minutes:
>> 
>> Margaret: 2 changes proposed: move to single unique short ID (UUID)
>>   and allow for additional info to be a part of the ID. So can we
>>   try to reach consensus on each?
>> 
>> Who thinks we should move to one unique format?
>>  (a couple of hands; 2nd time asking had about 10 hands)
>> Who thinks we should not use a single unique format?
>>  (no hands)
>>  OK. Single unique.
>> 
>> So, I would like to see this discussion take place before the document
>> progresses.
>> 
>> Thanks,
>> Ian
>> 
>> 
>> 
>>> On 14 Jul 2015, at 17:18, Hui Deng <denghui02@hotmail.com
>>> <mailto:denghui02@hotmail.com <mailto:denghui02@hotmail.com>>> wrote:
>>> 
>>> Hello all,
>>> 
>>> We would like to have a 3 weeks WGLC for the below document:
>>> http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-id/ <http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-id/>
>>> 
>>> Please help to send your comments to this thread.
>>> This WGLC will end on Aug. 5th.
>>> 
>>> Many thanks
>>> 
>>> DENG Hui
>>> _______________________________________________
>>> mif mailing list
>>> mif@ietf.org <mailto:mif@ietf.org> <mailto:mif@ietf.org <mailto:mif@ietf.org>>
>>> https://www.ietf.org/mailman/listinfo/mif <https://www.ietf.org/mailman/listinfo/mif>
>> 
>> 
>> 
>> _______________________________________________
>> mif mailing list
>> mif@ietf.org <mailto:mif@ietf.org>
>> https://www.ietf.org/mailman/listinfo/mif <https://www.ietf.org/mailman/listinfo/mif>