Re: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt

Tina TSOU <tena@huawei.com> Thu, 13 December 2007 06:38 UTC

Return-path: <dime-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2hiR-000690-9f; Thu, 13 Dec 2007 01:38:39 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2hiQ-0005zy-8Z for dime@ietf.org; Thu, 13 Dec 2007 01:38:38 -0500
Received: from szxga04-in.huawei.com ([61.144.161.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2hiM-0001WF-Ux for dime@ietf.org; Thu, 13 Dec 2007 01:38:38 -0500
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSZ002CN6F0J6@szxga04-in.huawei.com> for dime@ietf.org; Thu, 13 Dec 2007 14:37:48 +0800 (CST)
Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSZ00FW86EZ4L@szxga04-in.huawei.com> for dime@ietf.org; Thu, 13 Dec 2007 14:37:48 +0800 (CST)
Received: from z24109b ([10.70.76.84]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JSZ00CGV6EZH4@szxml03-in.huawei.com> for dime@ietf.org; Thu, 13 Dec 2007 14:37:47 +0800 (CST)
Date: Thu, 13 Dec 2007 14:37:47 +0800
From: Tina TSOU <tena@huawei.com>
Subject: Re: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt
To: Preeti Shandilya <preeti.shandilya@aricent.com>, jouni.korhonen@teliasonera.com
Message-id: <013301c83d52$ace0ded0$544c460a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-Priority: 3
X-MSMail-priority: Normal
References: <OF5116DC52.0E91427D-ON652573AF.001775F6-652573AF.0018B0A7@aricent.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd
Cc: dime@ietf.org, gshafran@traffixsystems.com
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1657849467=="
Errors-To: dime-bounces@ietf.org

Dear Preeti,
My comments are below demarked with [Tina: ...].

B. R.
Tina
  ----- Original Message ----- 
  From: Preeti Shandilya 
  To: jouni.korhonen@teliasonera.com 
  Cc: dime@ietf.org ; gshafran@traffixsystems.com 
  Sent: Wednesday, December 12, 2007 12:29 PM
  Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt



  Hi Jouni ! 

  In my opinion, if it is required that all the messages to follow the same proxy node(so that proxy can apply charging) , this shall be specific node's routing policy. i.e Source,  while selecting a route, it should always end up selecting the proxy node for sending the message. I don't think there is any need of standardization of routing policy for this specific purpose. While selecting the route, nodes can look into the type of service also inside the message which is to be routed further. 
  [Tina: Stateful proxy agent routing is a common problem. Basing on service type doesn't' work, as maybe many nodes will process same service. This is the issue this I-D will resolve, how to select among multiple service nodes.]

  regards 
  preeti 



        <jouni.korhonen@teliasonera.com> 
        12/12/2007 04:19 AM 

       To <glenzorn@comcast.net>  
              cc <dime@ietf.org>, <gshafran@traffixsystems.com>, Preeti Shandilya/HSS@HSS, <tasveren@sonusnet.com>  
              Subject RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt 

              

       




  Glen,

  > > I am not sure why there is a requirement for subsequent session 
  > > oriented message to traverse the same intermediary hops which the 
  > > initial message has traversed.
  > 
  > What if some of the intermediates are stateful and e.g.
  > collect charging data by tracking the user session?
  > 
  > [gwz]
  > I must admit that I cannot think of a single (real-life) 
  > scenario where this kind of thing would be desirable (let 
  > alone required).  Would you mind describing one in detail?
  > [/gwz]

  References to literature were given earlier in this thread ;)

  Anyway, assume two providers connected via "roaming infrastructure
  cloud" that cannot guarantee same AAA routes deterministically. The
  visited provider has outsourced its AAA based roaming charging to
  third party proxies within the "cloud" (each provider may have their
  own "third party"). 

  /Jouni



  ***********************  Aricent-Restricted   *********************** "DISCLAIMER: This message is proprietary to Aricent  and is intended solely for the use of 
the individual to whom it is addressed. It may contain privileged or confidential information and should not be 
circulated or used for any purpose other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for 
loss or damage arising from the use of the information transmitted by this email including damage from virus."
 



------------------------------------------------------------------------------


  _______________________________________________
  DiME mailing list
  DiME@ietf.org
  https://www1.ietf.org/mailman/listinfo/dime
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime