Subject: RE: [Dime] Summary of 3588bis Issues Status

From: "STURA, Marco, VF-IT" <[email-masked]>
Date: Wed, 19 Jul 2006 11:11:41 +0200

See in line.

Regards
Marco

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]] 
Sent: martedì 18 luglio 2006 18.52
To: STURA, Marco, VF-IT; Victor Fajardo
Cc: [email-masked]
Subject: RE: [Dime] Summary of 3588bis Issues Status

[.. snip ..]
> I agree with your example above regarding destination-host. It is
> required in the case of ASR (and perhaps some other message) though I
> guess I was stating a case which is a little bit different than your
> example above. I was thinking of the following case:
>
> clients[1,2,3...x] <--- relay1 <---- relay2 <---- server
>
> in this case relay2 will not be able to route using dest-host. This is
> where dest-realm and app id becomes important. In this case app id of 0
> might not work as well ... or maybe I'm wrong.
>
> [MSt] In this case R1 would advertise it self as a relay (i.e.
> 0xffffffff) it won't advertise app id x or y or z. So, any app id
> would be routed to R1 by R2.
[TOLGA] Let me try to further refine the scenario:
              *****************************
              *  Realm A                  *
              *                           *
              *           +---------+     *
              *        +--+C1 App=X |     *
              * +----+ |  +---------+     *
         +----*-+ P1 +-+  +---------+     *
+---+  +-+--+ * +----+----+C2 App=Y |     *
|S1 +--+ R1 | *           +---------+     *
+---+  +-+--+ *                           *
         |    * +----+                    *
         +----*-+ P2 +----+---------+     *
              * +----+    |C3 App=Z |     *
              *           +---------+     *
              *                           *
              *****************************
In this case, R1 wouldn't have enough knowledge to route the message
properly to the correct proxy just by looking to the App-Id in the message
header, if App-Id is populated with "0".

[MSt] I think you assume P1 and P2 advertise supports for App x/y and App z respectively but I would rather consider this configuration an academic use case since typically you have only one logical Proxy as a interconnect point for a given realm in real deployments as a central point for policy enforcement. However, let see whether a server initiated message using Destination-Host and app id 0 based routing works.

S1 sends ASR to C3 (C3 diameter identity in Destination-Host AVP) app id 0. In the realm-based routing table R1 will certainly find a match for realm A and app id 0, say for instance the match is for P1. ASR is routed to P1, which doesn't have C3 in its peer table and then answers with DIAMETER_UNABLE_TO_DELIVER. R1 attempts then to deliver the message via the alternative entry for Realm A, hence P2. P2 now deliver the message to C3. So, app-id 0 works at the end if Destination-Host based routing is used and, actually, is to be used for certain server initiated messages as also defined in RFC 3588 in section 6.1. 

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 19 Jul 2006 08:18:05 -0400

Marco,

Please see below for comments.

   Thanks,
   Tolga

> From: STURA, Marco, VF-IT [mailto:[email-masked]]
> Sent: Wednesday, July 19, 2006 5:12 AM
> To: Tolga Asveren; Victor Fajardo
> Cc: [email-masked]
> [MSt] I think you assume P1 and P2 advertise supports for App x/y
> and App z respectively but I would rather consider this
> configuration an academic use case since typically you have only
> one logical Proxy as a interconnect point for a given realm in
> real deployments as a central point for policy enforcement.
> However, let see whether a server initiated message using
> Destination-Host and app id 0 based routing works.
[TOLGA]To me this configuration is not unrealistic, because Realm-A is
supporting multiple applications and that may require different policy
enforcement processing per application. Maybe a better configuration would
be to have a gateway relay in Realm-A to provide a single point of enterance
but that wouldn't change anything in the context of current discussion.
>
> S1 sends ASR to C3 (C3 diameter identity in Destination-Host AVP)
> app id 0. In the realm-based routing table R1 will certainly find
> a match for realm A and app id 0, say for instance the match is
> for P1. ASR is routed to P1, which doesn't have C3 in its peer
> table and then answers with DIAMETER_UNABLE_TO_DELIVER. R1
> attempts then to deliver the message via the alternative entry
> for Realm A, hence P2. P2 now deliver the message to C3. So,
> app-id 0 works at the end if Destination-Host based routing is
> used and, actually, is to be used for certain server initiated
> messages as also defined in RFC 3588 in section 6.1.
[TOLGA]Probably this is not the optimum way to achieve routing, especially
considering that it would happen statistically for half of the session
life-cycle related messages, if App-Id=0 is used.

---

From: Tony Zhang <[email-masked]>
Date: Fri, 21 Jul 2006 11:43:07 +0800

Hi Macro:

[Tony]Because the Application Id 0,not advertisement in CER/CEA,so it means each realm will use the peet table select next hop,almost peer table have many peer can select,also include peer of receive the request. so it can happen loop routing.(maybe can add one process avoid this,when routing should input peer name of receive the request.).the other problem,after retry many peer ,then we find correct route,it consume long time,maybe the client already timer expire.also application id use for effectively routing,but for above the case ,it is not like this.

sorry about i discuss this again,after 2004's dicuss,it is likely many people confusion.if this time have same conlusion maybe still have same problem.

Thanks!
Tony

----- Original Message ----- 
From: "STURA, Marco, VF-IT" <[email-masked]>
To: "Tolga Asveren" <[email-masked]>; "Victor Fajardo" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, July 19, 2006 5:11 PM
Subject: RE: [Dime] Summary of 3588bis Issues Status

See in line.

Regards
Marco

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]] 
Sent: martedì 18 luglio 2006 18.52
To: STURA, Marco, VF-IT; Victor Fajardo
Cc: [email-masked]
Subject: RE: [Dime] Summary of 3588bis Issues Status

[.. snip ..]