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

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 25 Nov 2007 10:57:48 +0100

I read through 
http://tools.ietf.org/wg/dime/draft-tsou-dime-base-routing-ext-03.txt

At this point in time I only have high-level comments.

I am not sure about the usefulness of the proposed mechanism. In some 
sense you dynamically establish an explicit route based on the initial 
routing of the message. Then, this information is used for subsequent 
messages. When something changes along the path then a new route is 
being "established" and cached by the originator.

Diameter routes do not regularly change. If they change then there is a 
good reason (e.g., failure of a node).
This mechanism only seems to be useful for the cases where Diameter 
routes change because of some irrelevant reason but routing through the 
explicit path would still be possible.

Is there some evidence that the proposed mechanism would actually be 
helpful?
Do we have some real-world data indicating that this is indeed a problem 
rather than an academic exercise?

Ciao
Hannes

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: Tina TSOU <[email-masked]>
Date: Mon, 26 Nov 2007 17:14:07 +0800

Dear Hannes,
Thank you for your review:)
Please see my comments in line demarked as [Tina: ...].

B. R.
Tina
--------------------------------------------------------
Mondays aren't so bad; and pigs have wings...
  ----- Original Message ----- 
  From: Hannes Tschofenig 
  To: [email-masked] 
  Sent: Sunday, November 25, 2007 5:57 PM
  Subject: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt

  I read through 

  Diameter routes do not regularly change. If they change then there is a 
  good reason (e.g., failure of a node).
  This mechanism only seems to be useful for the cases where Diameter 
  routes change because of some irrelevant reason but routing through the 
  explicit path would still be possible.
  [Tina: There is Relay Agent in Diameter routing path, at the same time, in the case it has relative many next hop nodes, routing probably changes.
  It is because that the Diameter Relay Agent is likely to select the next hop node by random.
  In Diameter Base Protocol, usually when session starts, the Destination-Host is not appointed. Only the Destination-Realm is appointed. However,
  The subsequent requests in the session need to appoint Destination-Host to assure it is routed to the same server, as the routing may changes.
  And the mechanism define by this protocol, is to assure that it is routed to the intermediate stateful Proxy Agent.]

  Is there some evidence that the proposed mechanism would actually be 
  helpful?
  [Tina: Please look at the "Figure 1: Generic Stateful Proxy Problem" in draft-tsou-dime-base-routing-ext-03.txt.
  After a Diameter Relay Agent, there are two stateful Proxy Agents.

                VISITED NETWORK     |    HOME NETWORK
                                    |
        +--------+     +--------+   |   +--------+
        | Client |<--->| Relay1 |<----->| Proxy1 |
        +--------+     +--------+   |   +--------+\
                                 \  |              \+-------------+
                                  \ |               | Home Server |
                                   \|              /+-------------+
                                    \   +--------+/
                                    |---| Proxy2 |
                                    |   +--------+

  ]

  Do we have some real-world data indicating that this is indeed a problem 
  rather than an academic exercise?
  [Tina: Here are some application with stateful Proxy Agent in 3GPP and ETSI TISPAN. I think that if there is stateful Proxy Agent, such mechanism is needed.
  [TS23.234]
                3GPP, "3GPP system to Wireles Local Area Network (WLAN)
                interworking; System description", 3GPP TS 23.234 Version
                7.4.0 2006.
  Here, 3GPP AAA Proxy is a stateful Proxy Agent.

  RES/TISPAN-02045-NGN-R2  V0.0.5 
  ETSI Standard
  Telecommunications and Internet converged Services and
  Protocols for Advanced Networking (TISPAN);
  NGN Functional Architecture;
  Network Attachment Sub-System (NASS)

  Here, in Visited NGN Network, the UAAF, CLF are also in this case.
  ]

  Ciao
  Hannes