Re: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01

Alexandru Petrescu <alexandru.petrescu@gmail.com> Sat, 25 April 2015 12:17 UTC

Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C686A1A1A00 for <dmm@ietfa.amsl.com>; Sat, 25 Apr 2015 05:17:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level:
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 00H8oErdj-VI for <dmm@ietfa.amsl.com>; Sat, 25 Apr 2015 05:17:57 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 027D21A19F6 for <dmm@ietf.org>; Sat, 25 Apr 2015 05:17:56 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t3PCHrh5017731; Sat, 25 Apr 2015 14:17:53 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 09DF4201982; Sat, 25 Apr 2015 14:18:52 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id EE620200D0C; Sat, 25 Apr 2015 14:18:51 +0200 (CEST)
Received: from [127.0.0.1] ([132.166.84.67]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t3PCHLlA030355; Sat, 25 Apr 2015 14:17:22 +0200
Message-ID: <553B85D1.90107@gmail.com>
Date: Sat, 25 Apr 2015 14:17:21 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: sarikaya@ieee.org
References: <551C0877.1060100@gmail.com> <552F4165.9020300@gmail.com> <5536AB1E.6060507@gmail.com> <CAC8QAcc6mDoBC6x9QJPsyrSv092Kv5b+LZCUgy_mFzJjk0OTFA@mail.gmail.com> <5537D047.5040502@gmail.com> <CAC8QAce+EQWWEc1PwE9sEOhsvMPS8kEGAd9g=av6swHYMUba-Q@mail.gmail.com> <5539FE54.2030103@gmail.com> <CAC8QAcfqUFOkdqvaVfTEzzaC5n8K9GLZubXE+05MtXT2ieiDaw@mail.gmail.com>
In-Reply-To: <CAC8QAcfqUFOkdqvaVfTEzzaC5n8K9GLZubXE+05MtXT2ieiDaw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/MqlB6ltgav7DBCwGPAQpDU7uhyo>
Cc: sofiane.imadali@gmail.com, Basavaraj Patil <bpatil1@gmail.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Apr 2015 12:18:00 -0000

Le 24/04/2015 21:22, Behcet Sarikaya a écrit :
> I am still not convinced.
> At home I have LTE.
> LTE can be 3G if it is somewhat degraded and 3G is also available, so
> no reason for inter technology handoff.

YEs there is reason.

At home one may prefer the cheap 802.11ac instead of 3G.  The bandwith 
improvement is huge.

> I am also concerned on some other MN ids proposed like RFid, what is
> the assumption there? Is it that the sensor node will have Mobile IP
> client?
> To that I say, give me a break.

Break.

But the MN-ID as RFID does not necessarily mean it runs a MIP client. 
In some deployment of buses the RFID is on the passenger and the mobile 
router in the bus running Mobile IP uses another MN-ID form.  YEt they 
authenticate to the same server, using MN-ID concept.

I think yes, MN-ID should be independent of Mobile IP, but sometimes 
work together.

Alex

>
> Behcet
> Behcet
>
> On Fri, Apr 24, 2015 at 3:27 AM, Alexandru Petrescu
> <alexandru.petrescu@gmail.com> wrote:
>> Le 23/04/2015 19:11, Behcet Sarikaya a écrit :
>>>
>>> On Wed, Apr 22, 2015 at 11:45 AM, Alexandru Petrescu
>>> <alexandru.petrescu@gmail.com> wrote:
>>>>
>>>> Le 22/04/2015 18:06, Behcet Sarikaya a écrit :
>>>>>
>>>>>
>>>>>     Hi Alex,
>>>>>
>>>>> On Tue, Apr 21, 2015 at 2:55 PM, Alexandru Petrescu
>>>>> <alexandru.petrescu@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>> Le 16/04/2015 06:58, Jouni Korhonen a écrit :
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Folks,
>>>>>>>
>>>>>>> The adoption call for this I-D has ended. There is a clear concensus
>>>>>>> to
>>>>>>> adopt the I-D as a working group item.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I support its adoption.
>>>>>>
>>>>>> We have been working with an identifier specific to automobiles to use
>>>>>> to
>>>>>> realize access control.  Identifying an entire set of IP nodes deployed
>>>>>> in a
>>>>>> vehicle is different than identifying an end-user like address@realm.
>>>>>>
>>>>>> We looked for such an identifier and believe the VIN (Vehicle
>>>>>> Identification
>>>>>> Number) be a good candidate.
>>>>>>
>>>>>> One would consider using one type, like type 40, to encode the VIN or
>>>>>> parts
>>>>>> of it, into an MN-ID.
>>>>>>
>>>>>> The questions to the group are the following:
>>>>>> - is VIN considered private information? (in deployments it is private
>>>>>>      to a certain extent, but publicly avaliable to cameras or in public
>>>>>>      databases to another extent).
>>>>>> - is the MN-ID type 40 ok for it.
>>>>>> - is one type sufficient or should there be subtypes.
>>>>>
>>>>>
>>>>>
>>>>> What is your model here in providing Internet access to the car?
>>>>> As you may know, operators in US are deploying systems that connect
>>>>> the car to their LTE network upstream and downstream is the passengers
>>>>> in the car that access over Wi-Fi.
>>>>> With LTE, you get mobility support which is based on fixed anchoring.
>>>>> I cc'ed to Raj who works on these types of technologies.
>>>>> The ID there is the IMSI. I don't think vin is used.
>>>>
>>>>
>>>>
>>>> The model of Internet access to the cars for cars currently on market in
>>>> Europe is the same - the LTE technology is used, using the IMSI as an
>>>> identifier.  However, that does not use MN-ID, is only IPv4, is not WiFi
>>>> and
>>>> does not resist to cellular generation upgrades to 5G and beyond.
>>>
>>>
>>> I don't understand the handover scenario. I think you are mixing the
>>> car and the passengers in the car.
>>> LTE is available on a large geography, why should you handover the
>>> upstream traffic to Wi-Fi?
>>
>>
>> When the car arrives home it connects to the WiFi available in home, thus
>> handing over from LTE.  This is a sold use-case at e.g. Tesla.  The WiFi
>> hotspot can be the one deployed in-house, in-garage, or the WiFi offered by
>> the electrical recharging stations.
>>
>> Other manufacturers propose scenarios in which car's WiFi antenna switches
>> from being an in-car hotspot to being a Client to outside wifi.
>>
>> Some consider 802.11p (wifi for vehicles) to be deployed along highways and
>> cars to perform handovers between these 802.11p access points.
>>
>> Next time on highway scan for WiFi - one is surprised by the number of
>> hotspots driving around, even though often they use portals.
>>
>> There are many commercially considered scenarios involving WiFi handovers
>> for cars.
>>
>> Alex
>>
>>
>>>
>>> Behcet
>>>>
>>>>
>>>> Newer models will feature IPv6 in addition to IPv4, WiFi handover from
>>>> LTE
>>>> to house's hotspot, continuous sessions, and over-the-air software update
>>>> for cheap upgradeability to future generation 5G and beyond.
>>>>
>>>> In this context it is hard to imagine IMSI will be there for a long time
>>>> in
>>>> a given car, and a more permanent identifier is needed.
>>>>
>>>> To Raj - is LTE considering other kinds of identifiers for access control
>>>> (other than IMSI) for vehicular environments, like V2X?
>>>>
>>>> Alex
>>>>
>>>>
>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Behcet
>>>>>>
>>>>>>
>>>>>>
>>>>>> Yours,
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> - Jouni & Dapeng
>>>>>>>
>>>>>>> 4/1/2015, 8:02 AM, Jouni Korhonen kirjoitti:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Folks,
>>>>>>>>
>>>>>>>> This emails starts a two week call for the I-D
>>>>>>>>       draft-perkins-dmm-4283mnids-01
>>>>>>>> to confirm the aadoption s a DMM WG document. The call ends April
>>>>>>>> 15th
>>>>>>>> EOB PST.
>>>>>>>>
>>>>>>>> Express your support or opposition to the mailing list. During the
>>>>>>>> IETF92 meeting we got 7 voices for the adoption so at least the same
>>>>>>>> amount supporting emails should be expected.
>>>>>>>>
>>>>>>>> - Jouni & Dapeng
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> dmm mailing list
>>>>>>> dmm@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> dmm mailing list
>>>>>> dmm@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>