Re: [fmc] [Int-area] draft-boucadair-intarea-host-identifier-scenarios

<mohamed.boucadair@orange.com> Tue, 11 December 2012 09:32 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: fmc@ietfa.amsl.com
Delivered-To: fmc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F094C21F87A2; Tue, 11 Dec 2012 01:32:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.244
X-Spam-Level:
X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Guh9eKEQgyCc; Tue, 11 Dec 2012 01:32:02 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8419F21F878B; Tue, 11 Dec 2012 01:32:01 -0800 (PST)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 3AD193245C4; Tue, 11 Dec 2012 10:32:00 +0100 (CET)
Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 1560627C06E; Tue, 11 Dec 2012 10:32:00 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Tue, 11 Dec 2012 10:31:59 +0100
From: mohamed.boucadair@orange.com
To: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
Date: Tue, 11 Dec 2012 10:31:58 +0100
Thread-Topic: [Int-area] draft-boucadair-intarea-host-identifier-scenarios
Thread-Index: AQHN1Eq1hdFbUszkvEqG84In7vT9DJgRmtZAgADO0+aAAMn8oA==
Message-ID: <94C682931C08B048B7A8645303FDC9F36E9B6B6D91@PUEXCB1B.nanterre.francetelecom.fr>
References: <94C682931C08B048B7A8645303FDC9F36E99E2D9FA@PUEXCB1B.nanterre.francetelecom.fr> <2671C6CDFBB59E47B64C10B3E0BD59230338CCCBC2@PRVPEXVS15.corp.twcable.com>, <94C682931C08B048B7A8645303FDC9F36E99E2E2C2@PUEXCB1B.nanterre.francetelecom.fr> <FDFF3C82-4766-4F09-86FC-2E9CE214D2C7@huawei.com>, <94C682931C08B048B7A8645303FDC9F36E9B6B67B2@PUEXCB1B.nanterre.francetelecom.fr> <38E21423-7972-4EFE-A233-B2CB37448B7B@huawei.com>
In-Reply-To: <38E21423-7972-4EFE-A233-B2CB37448B7B@huawei.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E9B6B6D91PUEXCB1Bnante_"
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.12.11.90324
Cc: "draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org" <draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org>, "int-area@ietf.org" <int-area@ietf.org>, "fmc@ietf.org" <fmc@ietf.org>, "George, Wes" <wesley.george@twcable.com>
Subject: Re: [fmc] [Int-area] draft-boucadair-intarea-host-identifier-scenarios
X-BeenThere: fmc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Fixed Mobile Convergence <fmc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/fmc>, <mailto:fmc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fmc>
List-Post: <mailto:fmc@ietf.org>
List-Help: <mailto:fmc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fmc>, <mailto:fmc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Dec 2012 09:32:03 -0000

Hi Tina,

Thank you for the clarification. I updated the draft with a pointer to SLNAT44.

I prefer to not modify fig.6 (keep it simple + we are not dealing with signalling flows issued from the UE).

Thanks for the review.

Cheers,
Med

________________________________
De : Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com]
Envoyé : lundi 10 décembre 2012 20:04
À : BOUCADAIR Mohamed OLNC/OLN
Cc : George, Wes; fmc@ietf.org; int-area@ietf.org; draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org
Objet : Re: [Int-area] draft-boucadair-intarea-host-identifier-scenarios

Dear Med et al,
In line...

Thank you,
Tina

On Dec 9, 2012, at 10:57 PM, "mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>" <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> wrote:

Hi Tina,

Many thanks for the comments.

Please see inline.

Cheers,
Med

________________________________
De : Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com]
Envoyé : vendredi 7 décembre 2012 08:16
À : BOUCADAIR Mohamed OLNC/OLN
Cc : George, Wes; fmc@ietf.org<mailto:fmc@ietf.org>; int-area@ietf.org<mailto:int-area@ietf.org>; draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org<mailto:draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org>
Objet : Re: [Int-area] draft-boucadair-intarea-host-identifier-scenarios

Dear Med et al,
In general, I like the current version. Some comments are below.

1.      From my understanding, this document provides the use cases for the issues and analysis in "draft-ietf-intarea-nat-reveal-analysis". Is it correct? If it is , I suggest this document be referenced in "nat-reveal-analysis".
[Med] nat-reveal-analysis draft inherits its scope from RFC6269. The use cases draft adopts a more generic scope in which host identification issue is encountered (this can be caused by address sharing, tunnelling, involvement of multiple administrative entities, etc.).

2.      Regarding this document, in the section of CGN use case, the stateless NAT44 case should be included.
[Med] Do you mean 1:1 NAT?

[Tina] I meant the case in this document: http://datatracker.ietf.org/doc/draft-tsou-stateless-nat44/, did not mean to just promote my own draft though.

3.      For A+P section, the MAP/Lw4over6 cases may be considered.
[Med] OK. I will add a pointer to MAP and Lw4over6 as examples.

4.      In figure 6, the UE may have an interface with AF to initiate the session request, e.g., SIP.
[Med] What does that mean? The goal of fig.6 is to illustrate the case where there is a host identification issue.

[Tina] In section 7, it says "The main issue is: PCEF, PCRF and AF all receive information bound to the same UE but without being able to correlate between the piece of data visible for each entity."
In PCRF architecture, the AF receives service request from the UE for service establishment, which is one of the ways for AF to receive UE information, e.g., user ID. To make the architecture more generic, there should be an interface between AF and UE.