Re: [hiaps] Hiaps use cases

<mohamed.boucadair@orange.com> Wed, 15 January 2014 14:12 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: hiaps@ietfa.amsl.com
Delivered-To: hiaps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8250D1AE0D2 for <hiaps@ietfa.amsl.com>; Wed, 15 Jan 2014 06:12:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.548
X-Spam-Level:
X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 jHTnduowtcdZ for <hiaps@ietfa.amsl.com>; Wed, 15 Jan 2014 06:12:00 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 935351ADFF8 for <hiaps@ietf.org>; Wed, 15 Jan 2014 06:11:59 -0800 (PST)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 4781432426A; Wed, 15 Jan 2014 15:11:47 +0100 (CET)
Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 20B2A238048; Wed, 15 Jan 2014 15:11:47 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Wed, 15 Jan 2014 15:11:46 +0100
From: <mohamed.boucadair@orange.com>
To: "Roland.Schott@telekom.de" <Roland.Schott@telekom.de>, "dwing@cisco.com" <dwing@cisco.com>, "sarikaya@ieee.org" <sarikaya@ieee.org>
Date: Wed, 15 Jan 2014 15:11:45 +0100
Thread-Topic: [hiaps] Hiaps use cases
Thread-Index: Ac7wglGajninLQZAQAK81fNj2YUgkwAV2QUQCEgkkYA=
Message-ID: <94C682931C08B048B7A8645303FDC9F36F45EC42F8@PUEXCB1B.nanterre.francetelecom.fr>
References: <CAC8QAcd1bVyoz=u9+C2P3pbB2YOJE0TXV44uUJcCouC61anQMg@mail.gmail.com> <726C15B0-DC5F-4438-8EEE-EEA650CE562E@cisco.com> <CAC8QAcchAyiC4PssOwrf+-Zi5Xn7u+Ccd7Y5yNC-dZn-b2k55Q@mail.gmail.com> <2DD9F847-2802-49D5-8118-0CBCEE22F855@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D18DE8F3762@HE111648.emea1.cds.t-internal.com>
In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D18DE8F3762@HE111648.emea1.cds.t-internal.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: multipart/related; boundary="_004_94C682931C08B048B7A8645303FDC9F36F45EC42F8PUEXCB1Bnante_"; type="multipart/alternative"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.14.55715
Cc: "hiaps@ietf.org" <hiaps@ietf.org>, "xueli@huawei.com" <xueli@huawei.com>, "Dirk.von-Hugo@telekom.de" <Dirk.von-Hugo@telekom.de>
Subject: Re: [hiaps] Hiaps use cases
X-BeenThere: hiaps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" <hiaps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hiaps>, <mailto:hiaps-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hiaps/>
List-Post: <mailto:hiaps@ietf.org>
List-Help: <mailto:hiaps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hiaps>, <mailto:hiaps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 14:12:03 -0000

Dear Roland,

Apologies for the delay to answer this message.

Please see inline.

Cheers,
Med

De : Roland.Schott@telekom.de [mailto:Roland.Schott@telekom.de]
Envoyé : mercredi 4 décembre 2013 11:36
À : dwing@cisco.com; sarikaya@ieee.org
Cc : hiaps@ietf.org; Dirk.von-Hugo@telekom.de; BOUCADAIR Mohamed IMT/OLN; xueli@huawei.com
Objet : AW: [hiaps] Hiaps use cases

Hi all,

regarding




   (5)  Section 3.5: Policy and Charging Architectures



RS: I do not understand why double NAT is not described or allowed

[Med] Where do you want to position the second NAT?





   (6)  Section 3.6: Cellular Networks



RS: do we have here also the use case for using private

Ipv4 addresses?

[Med] Yes.





   (7)  Section 3.7: Femtocells



RS: this use case seems similar to the WiFi use case and

belongs IMHO to the "use case" heterogeneous networks in general

[Med] Makes sense. Suggestions to re-organise the text are more than welcome.




   (9)  Section 3.9: Emergency Calls

RS: This is a general use case and must be discussed for all use cases
[Med] Not sure I got your point here. The issue captured in this use case is to determine which location server need to be contacted to get the location of the caller.


What about the use case where mobile and/or fixed access are backup links for each other,
e.g. BBF use case?
[Med] Increasing the serviceability of the RG can be indeed ensured by backup lines; with or without maintaining the same address assigned to the RG. I can understand also the backup procedure can be implemented with or without preserving session continuity. Now back to the host identification issue, can you explicit which issue are you referring to? Thanks.

Is it included in Overlay Networks?


[cid:image001.png@01CF1203.432B5970]



Regards

Roland




Von: hiaps [mailto:hiaps-bounces@ietf.org] Im Auftrag von Dan Wing
Gesendet: Mittwoch, 4. Dezember 2013 00:49
An: sarikaya@ieee.org<mailto:sarikaya@ieee.org>
Cc: hiaps@ietf.org<mailto:hiaps@ietf.org>; von Hugo, Dirk; Mohamed Boucadair; Xueli
Betreff: Re: [hiaps] Hiaps use cases


On Dec 3, 2013, at 9:08 AM, Behcet Sarikaya <sarikaya2012@gmail.com<mailto:sarikaya2012@gmail.com>> wrote:



On Mon, Dec 2, 2013 at 1:28 PM, Dan Wing <dwing@cisco.com<mailto:dwing@cisco.com>> wrote:

On Dec 2, 2013, at 8:32 AM, Behcet Sarikaya <sarikaya2012@gmail.com<mailto:sarikaya2012@gmail.com>> wrote:

I started a new tread on the use case issue that Med brought up.
Based on what Med said in his previous mail:

>IMHO before having solution-oriented discussion, let's see first if people
>understand well the problem space and the set of use cases identified
>so far.
for this we currently have:
http://tools.ietf.org/id/draft-boucadair-intarea-host-identifier-scenarios-03.txt

It lists:

   (1)  Section 3.1: Carrier Grade NAT (CGN)

   (2)  Section 3.2: A+P (e.g., MAP )

   (3)  Section 3.3: Application Proxies

   (4)  Section 3.4: Provider Wi-Fi

   (5)  Section 3.5: Policy and Charging Architectures

   (6)  Section 3.6: Cellular Networks

   (7)  Section 3.7: Femtocells

   (8)  Section 3.8: Overlay Networks (e.g., CDNs)

   (9)  Section 3.9: Emergency Calls


Are these use case well understood? Any issues with them?

I understand the first 4.  I understand the rest less.  Specifically, overlay networks (8) I understand because I have chatted several times with Brandon, but the I-D doesn't adequately motivate the use-case.  Emergency calls (9) is all over the map -- discusses solutions (which I believe is out of scope for the document, or should be?), some of which cannot work (specifically the location when using VPN cannot work).  Not sure of use-case #5, 6, or 7.

-d



There is also interest in combining Med's use cases draft with the prefix sharing use case draft and also in the process concentrating on some of them like emergency calls, CGNs and prefix sharing.
What do you think?
Behcet

but none of those are the 'roaming' situation which I believe Dirk von Hugo was concerned with, where he wanted an identifier to persist across network attach points.  (Veering into solutions, I wonder if an MPTCP-like connection identifier would solve the problem, even if MPTCP itself isn't used).

-d






and
http://tools.ietf.org/id/draft-sarikaya-aps-prefix-sharing-usecase-00.txt
We are expecting a new draft on this and I know we already have some people working on it.
Regards,
Behcet
_______________________________________________
hiaps mailing list
hiaps@ietf.org<mailto:hiaps@ietf.org>
https://www.ietf.org/mailman/listinfo/hiaps