Re: [Dime] Call for WG adoption: draft-jones-diameter-group-signaling-01

Tina TSOU <Tina.Tsou.Zouting@huawei.com> Fri, 13 April 2012 17:35 UTC

Return-Path: <Tina.Tsou.Zouting@huawei.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BFC11E809F for <dime@ietfa.amsl.com>; Fri, 13 Apr 2012 10:35:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dsz3EJ8ANZu for <dime@ietfa.amsl.com>; Fri, 13 Apr 2012 10:35:03 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6691111E809D for <dime@ietf.org>; Fri, 13 Apr 2012 10:35:03 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFE86515; Fri, 13 Apr 2012 13:35:03 -0400 (EDT)
Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Apr 2012 10:33:42 -0700
Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Apr 2012 10:33:49 -0700
Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.22]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Sat, 14 Apr 2012 01:33:41 +0800
From: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
To: "lionel.morand@orange.com" <lionel.morand@orange.com>
Thread-Topic: [Dime] Call for WG adoption: draft-jones-diameter-group-signaling-01
Thread-Index: AQHNEDyF4CFv35exeUKXaSyq14pyOpaLVqMggAsY1QCAAAktAIACngRg
Date: Fri, 13 Apr 2012 17:33:41 +0000
Message-ID: <62751006-3C94-4279-B962-382E27E4D49D@huawei.com>
References: <4C639074-1D3C-44E8-B2EB-D602681818A4@gmail.com> <C0E0A32284495243BDE0AC8A066631A80C92195F@szxeml526-mbx.china.huawei.com> <41608FF6-EAFA-49B1-9BCF-92C6A8D2D411@gmail.com>, <B11765B89737A7498AF63EA84EC9F57701439C21@ftrdmel1>
In-Reply-To: <B11765B89737A7498AF63EA84EC9F57701439C21@ftrdmel1>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "dime@ietf.org" <dime@ietf.org>, "dime-chairs@tools.ietf.org" <dime-chairs@tools.ietf.org>
Subject: Re: [Dime] Call for WG adoption: draft-jones-diameter-group-signaling-01
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Apr 2012 17:35:04 -0000

Sent from my iPad

On Apr 12, 2012, at 2:35 AM, "lionel.morand@orange.com" <lionel.morand@orange.com> wrote:

> Hi Jouni, Tina and Mark,
Merci, Lionel. Comments r in line.
> 
> I share the Jouni's point of view. If stateful proxies are required in the path, all messages related to the same sessions have to go through the same proxy.
You are right. Implementations should ensure this. However in group signalling only one (req-resp pair) group signalling message is exchanged between the client and the server. It can only take one of the session path between the client and the server. For server-initiated group signaling, implementations can still ensure "maintaining" the session path by indicating the follow up to happen at PER_SESSION level. The client initiated group signalling has no such provision in the current solution.
> 
> If an implementation allows relying on multiple stateful proxies to manage the same sessions, this implementation needs also to support a mechanism ensuring a consistent management of the session data contexts between proxies. But IMHO, this kind of implementation is and should remain out of scope of any Diameter protocol spec.
> 
> Regards,
> 
> Lionel
> 
> 
> 
> -----Message d'origine-----
> De : jouni korhonen [mailto:jouni.nospam@gmail.com] 
> Envoyé : jeudi 12 avril 2012 11:03
> À : Tina TSOU
> Cc : dime@ietf.org; dime-chairs@tools.ietf.org; mark@azu.ca
> Objet : Re: [Dime] Call for WG adoption: draft-jones-diameter-group-signaling-01
> 
> Tina,
> 
> 
> On Apr 5, 2012, at 2:41 AM, Tina TSOU wrote:
> 
>> Hi Jouni and Mark,
>> The problem statement is valid and the solution can work in basic scenarios. 
>> 
>> However the solution may have some limit in roaming scenario.
>> 
>> Consider a network having a WLAN AN (hosting a Diameter Client) requesting some 3G internet resources, visited network proxies and home network server as below:
>> 
>> Client -------------- <Visited n/w proxy 1> ---------- {Home network server}
>>        -------------- <Visited n/w proxy 2> ----------{Home network server}
>> 
>> The session path can be established through either of the visited n/w proxies. For all the messages of same session, client can ensure that the session path through stateful nodes is maintained. The visited n/w proxies would require that the session path be maintained for offline charging etc.
>> In this scenario, if client uses group signalling method to terminate all sessions in a group using GSTR, only the proxy in the GSTR-GSTA path will be aware of session termination. Since there are no follow-up messages, there is no mechanism to let the other proxy know that the sessions are terminated.
> 
> How this differentiates from a generic issue where someone
> puts a proxy on path that is supposed to stay on path and
> at the same time allows by deployment options an alternative
> path to take place? Like asking for trouble..
> 
> 
>> This problem can be avoided in Server initiated group signalling cases (GRAR & GASR) as the PER_SESSION mode can be used for follow up exchanges.
>> Thus the current solution has a limit if client uses group signalling method for session termination in roaming cases.
> 
> The problem could also be avoided by not doing such deployment
> where this can happen.
> 
> - Jouni
> 
>> 
>> I volunteer to work together with Mark to find a solution for this case.
>> 
>> I'm NOT aware of any IPR in this area.
>> 
>> 
>> Tina
>> 
>> 
>>> -----Original Message-----
>>> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of
>>> jouni korhonen
>>> Sent: Sunday, April 01, 2012 12:20 PM
>>> To: dime@ietf.org
>>> Cc: dime-chairs@tools.ietf.org
>>> Subject: [Dime] Call for WG adoption: draft-jones-diameter-group-
>>> signaling-01
>>> 
>>> 
>>> Folks,
>>> 
>>> During the Dime WG meeting in Paris we decided to adopt draft-jones-
>>> diameter-group-signaling-01
>>> "Diameter Group Signaling" as a working group I-D. The I-D is an input for
>>> the charter mile stone 'Protocol extension for bulk and group signaling'.
>>> 
>>> This mail starts a one week verification for the adoption. If you have
>>> strong concerns that the
>>> draft-jones-diameter-group-signaling-01 is not appropriate as a _basis_
>>> for the solution, then express your concerns on the mailing list by 8th
>>> April.
>>> 
>>> - Jouni & Lionel
>>> 
>>> 
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>