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

From: "STURA, Marco, VF-IT" <[email-masked]>
Date: Fri, 21 Jul 2006 09:18:13 +0200

Hi Tony,

Server initiated requests can only be sent in the context of existing sessions and routing must be done on the basis of Destination-Host to ensure that the request hits the correct client, so app id is not enough.

The routing problem you are discussing has to do with how a proxy can stay on the path during a session so that a server can send a request, say ASR or RAR, to Destination-Host via P1 to C1. As also suggested by Tolga

>I think it can be deducted to the generic problem of "How can a proxy stay >on the path during a session", so I believe this is the question to answer >(which we already discussed to some extent in the context of strict-routing >draft review)

So I think your issue can be discussed in that context, app id 0 for common messages I think is fine.

Regards
Marco

-----Original Message-----
From: Tony Zhang [mailto:[email-masked]] 
Sent: venerdì 21 luglio 2006 5.43
To: STURA, Marco, VF-IT; Tolga Asveren; Victor Fajardo
Cc: [email-masked]
Subject: Re: [Dime] Summary of 3588bis Issues Status

Hi Macro:

[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. 

[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 ..]
> 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

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

---

From: Tony Zhang <[email-masked]>
Date: Mon, 24 Jul 2006 13:59:31 +0800

Hi Marco:

    I also agree the generic problem of "How can a proxy stay >on the path during a session", but i think this problem is address the stateful proxy agent,acutal maybe still have stateless proxy agent.so the routing problem still in here.
    I still think the routing is common part,independent on start ,end ,interim session message.

Regards
Tony
----- Original Message ----- 
From: "STURA, Marco, VF-IT" <[email-masked]>
To: "Tony Zhang" <[email-masked]>; "Tolga Asveren" <[email-masked]>; "Victor Fajardo" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, July 21, 2006 3:18 PM
Subject: RE: [Dime] Summary of 3588bis Issues Status

Hi Tony,

Regards
Marco

-----Original Message-----
From: Tony Zhang [mailto:[email-masked]] 
Sent: venerdì 21 luglio 2006 5.43
To: STURA, Marco, VF-IT; Tolga Asveren; Victor Fajardo
Cc: [email-masked]
Subject: Re: [Dime] Summary of 3588bis Issues Status

Hi Macro:

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 ..]

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 24 Jul 2006 13:52:27 -0400

Hi all,

I guess there is still some contention regarding this issue so I suggest 
we defer it to the chairs for some guidance.

best regards,
victor

---

From: <[email-masked]>
Date: Thu, 27 Jul 2006 02:29:58 +0300

Tony,

During the initial work on Diameter, it was hoped that proxies would
be a rare occurance.  We assumed all proxies will be stateless.

If someone needs stateful proxies, I'd like to understand what the problem
stateful proxies are trying to solve is, and why the current solution
is insufficient.  Wit respect to the App ID = 0 issue, we assumed that
proxies are stateless.

John
>From: ext Tony Zhang [mailto:[email-masked]] 
>Sent: 24 July, 2006 02:00
>    I also agree the generic problem of "How can a proxy stay 
>>on the path during a session", but i think this problem is 
>address the stateful proxy agent,acutal maybe still have 
>stateless proxy agent.so the routing problem still in here.
>To: "Tony Zhang" <[email-masked]>; "Tolga Asveren" 
><[email-masked]>; "Victor Fajardo" <[email-masked]>
>Cc: <[email-masked]>
>Server initiated requests can only be sent in the context of 
>existing sessions and routing must be done on the basis of 
>Destination-Host to ensure that the request hits the correct 
>client, so app id is not enough.
>
>The routing problem you are discussing has to do with how a 
>proxy can stay on the path during a session so that a server 
>can send a request, say ASR or RAR, to Destination-Host via P1 
>to C1. As also suggested by Tolga
>
>>I think it can be deducted to the generic problem of "How can 
>a proxy stay >on the path during a session", so I believe this 
>is the question to answer >(which we already discussed to some 
>extent in the context of strict-routing >draft review)
>
>[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. 
>
>[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
>
>[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. 
>
>

---

From: Tony Zhang <[email-masked]>
Date: Thu, 27 Jul 2006 20:02:12 +0800

Hi John:
	When I read proxy agent definition in RFC3588:
   Proxies that wish to limit resources MUST maintain session state.
   All proxies MUST maintain transaction state.
   Since enforcing policies requires an understanding of the service
   being provided, Proxies MUST only advertise the Diameter applications
   they support.

Maybe almost the stateful proxy is more.

If With respect to the App ID = 0 issue, we assumed that
proxies are stateless.
I think use app Id = 0,the routing for some environment is not effective.
Tolga already give one network environment.

Thanks!
Tony.
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 27, 2006 7:30 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Dime] Summary of 3588bis Issues Status

Tony,

John