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

From: venkatesh devalapura nagabhushana <[email-masked]>
Date: Mon, 24 Jul 2006 08:38:32 +0530

Hi,

My comments inline:

On Sat, 2006-07-22 at 01:13 +0800, Ram O V Vishnu-A14676 wrote:
> Hi All,
> 
> Its *not* a good idea to use application id 0 for RAR, RAA, ASR, ASA, STR, STA. 
> 
> My reasons are: 
> 
> 1. My definition (in the absence of one in the RFC 3588) of "Diameter Common Message" is that - only the ones used in FSM in section 5.6 of RFC 3588 should be treated as common messages.
> 

[Venkatatesh] FSM defined in 5.6 is at connection level rather than at
session level. Hence the concept of "application id" should not be
applied here....... is my interpretation correct or am i missing
something here ?

> 2. In the place where Sessions are defined (in section 1.3) RFC 3588, it is mentioned that  "Each application SHOULD provide guidelines as to when a session begins and ends." So sessions are application level entities and hence session related messages (like ASR/STR) with app-id 0 does not make sense. They should be with specific application ids which maintain those sessions.
> 
> 3. I agree with Tony that this will break existing implementations of the base protocol. About the past discussions- RFC 3588 still stayed, it was not corrected, implementations have gone ahead - I guess we should take a fresh look.
> 
> About other RFCs using other interpretations, I think those should be corrected.
> 
> Regards,
> Vishnu.
> 
> Motorola India Electronics Pvt Ltd
> +91 9844178052
> [*] Motorola Internal Use Only
> 
> 
> 
> -----Original Message-----
> From: STURA, Marco, VF-IT [mailto:[email-masked]] 
> Sent: Friday, July 21, 2006 12:48 PM
> To: Tony Zhang; Tolga Asveren; Victor Fajardo
> Cc: [email-masked]
> Subject: RE: [Dime] Summary of 3588bis Issues Status
> 
> 
> 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
> 
> _______________________________________________
> 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 18:34:30 +0800

Hi All,
    I agree with this.
    also about below former discuss,i have one more comments:
    if application acually is a (set of) specifications that document how Diameter is extended for some particular purpose .why in the RFC3588 Accounting Message not use Application ID 0?

Thanks Regards
Tony

former discuss:
Tolga,

This is not the first time this issue has been discussed (see e.g. 
AAA archives around July 2004). What it really boils down to
is what exactly an "application" is. Quoting myself from two
years ago:

> This brings us back to the topic what an "application" actually
> is. It could mean e.g. a software module in a Diameter
> implementation, or a (set of) specifications that document how
> Diameter is extended for some particular purpose (such as SIP or
> Mobile IPv4).
>
> My reading of RFC3588 supports the latter interpretation (but I
> guess there is some room for disagreement and other interpretations
> as well...).

With this interpretation, it does not make sense to say that you send
a message _to_ an application, or that a message is intended _for_ an
application. Instead, you send a message defined _in_ some
application.

Back then, several others seemed to agree that RFC 3588 supports 
this interpretation. 

(How a Diameter server implementation is organized to modules and 
how the modules communicate is beyond the scope of RFC 3588.)

Best regards,
Pasi

----- Original Message ----- 
From: "Ram O V Vishnu-A14676" <[email-masked]>
To: "STURA, Marco, VF-IT" <[email-masked]>; "Tony Zhang" <[email-masked]>; "Tolga Asveren" <[email-masked]>; "Victor Fajardo" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, July 22, 2006 1:13 AM
Subject: RE: [Dime] Summary of 3588bis Issues Status

Hi All,

My reasons are: 

Regards,
Vishnu.

-----Original Message-----
From: STURA, Marco, VF-IT [mailto:[email-masked]] 
Sent: Friday, July 21, 2006 12:48 PM
To: Tony Zhang; Tolga Asveren; Victor Fajardo
Cc: [email-masked]
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 ..]