Subject: RE: [AAA-WG]: Message routing and vendor specific applications

From: <[email-masked]>
Date: Mon, 8 Apr 2002 14:31:35 +0300

Johan,

Do you want to supply the text?

John
> -----Original Message-----
> From: ext Johan Johansson [mailto:[email-masked]]
> Sent: 07 April, 2002 18:35
> To: aaa-wg
> Subject: [AAA-WG]: Message routing and vendor specific applications
> 
> 
> Issue:                   Message routing and vendor specific 
> applications
> Submitter name:          Johan Johansson
> Submitter email address: [email-masked]
> Date first submitted:    04-07-2002 
> Reference: 
> Document:                Base 
> Comment type:            Technical 
> Priority: 		 S 
> Section:                 2.7, 6.1, 6.1.6, 6.10, 9.7.1
> 
> Rationale/Explanation of issue:
> 
> We allow vendor specific applications with their own 
> "namespaces" but we 
> do not perform routing on them. Section 6.1.6 simply states:
> 
> Diameter request message routing is done via realms. A Diameter
>    message that is able to be proxied MUST include the target realm in
>    the Destination-Realm AVP. The realm MAY be retrieved from 
> the User-
>    Name AVP, which is in the form of a Network Access 
> Identifier (NAI).
>    The realm portion of the NAI is inserted in the Destination-Realm
>    AVP.
> 
>    Diameter agents MAY have a list of locally supported 
> realms, and MAY
>    have a list of externally supported realms. When a request is
>    received that includes a realm that is not locally supported, the
>    message is routed to the peer configured in the Realm Routing Table
>    table (see section 2.8).
> 
> On a side note this should probably be section 2.7, but the important 
> part is that nowhere in these paragraphs is per-application routing 
> mentioned, let alone vendor-specific such.
> 
> The preceding section 6.1 states
> 
> The Destination-Realm AVP MUST be present if the message is
>    proxiable.  Proxiable request messages MUST also contain either an
>    Acct-Application-Id AVP or an Auth-Application-Id AVP.
> 
> while 9.7.1 happily claims
> 
>    One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs
>    MUST be present. If the Vendor-Specific-Application-Id 
> grouped AVP is
>    present, it must have an Acct-Application-Id inside.
> 
> Pretty contradictory if you ask me.
> 
> Finally, the section 2.7 describing the realm based routing table says
> 
> 
>       - Application Identifier. A route entry can have a different
>         destination based on the Acct-Application-Id for accounting
>         messages) or Auth-Application-Id (for non-accounting messages)
>         of the message. This field MUST be used as a 
> secondary key field
>         in routing table lookups.
> 
> It seems to me that it would need to use vendor id *and* 
> application id 
> to perform a proper lookup.
> 
> Requested change:
> 
> The solution is conceptually simple: make the routing table 
> store vendor 
> id and application id and add text to 6.1.6 to take these 
> into account 
> when routing requests.
> 
> We now have two ways to identify the application of a 
> request. Either it 
> has a "naked" Acct/Auth-Application-Id *or* it has a grouped 
> Vendor-Specific-Application-Id AVP where the Vendor-Id is non-zero. 
> Granted, the Diameter standard vendor is an important special 
> case but 
> is it important enough to require a two-stage lookup?
> 
> What do you think?
> 
> I'll sneak in an editorial side-issue. Shouldn't we change
> 
> 
> 6.10  Vendor-Specific-Application-Id AVP
> 
>    The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type
>    Grouped and is used to advertise support of a vendor-specific
>    Diameter Application. Either the Auth-Application-Id or the Acct-
>    Application-Id AVP MAY be present. Exactly one of the Auth-
>    Application-Id and Acct-Application-Id AVPs MAY be present.
> 
> to
> 
> 6.10  Vendor-Specific-Application-Id AVP
> 
>    The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type
>    Grouped and is used to advertise support of a vendor-specific
>    Diameter Application. Exactly one of the Auth-
>    Application-Id and Acct-Application-Id AVPs MUST be present.
> 
> j
> 
>

---

From: Johan Johansson <[email-masked]>
Date: Mon, 08 Apr 2002 13:40:20 +0000

Sure. I just want to get the issue reviewed first to make sure I am not 
seeing a problem where there is none and then I'd want to see some 
reaction to the solution alternatives I have suggested.

j

---

From: Johan Johansson <[email-masked]>
Date: Wed, 10 Apr 2002 17:28:37 +0000

Please, someone comment on this one. I am reluctant to make a change 
that nobody has reviewed.

j

Johan Johansson wrote:

> Sure. I just want to get the issue reviewed first to make sure I am 
> not seeing a problem where there is none and then I'd want to see some 
>>> Date first submitted:    04-07-2002 Reference: 
>>> Document:                Base Comment type:            Technical 
>>> Priority:          S Section:                 2.7, 6.1, 6.1.6, 6.10, 
>>> 9.7.1
>>>
>>> We allow vendor specific applications with their own "namespaces" 
>>> but we do not perform routing on them. Section 6.1.6 simply states:
>>>
>>>   the Destination-Realm AVP. The realm MAY be retrieved from the User-
>>>   Name AVP, which is in the form of a Network Access Identifier (NAI).
>>>   Diameter agents MAY have a list of locally supported realms, and MAY
>>> On a side note this should probably be section 2.7, but the 
>>> important part is that nowhere in these paragraphs is 
>>> per-application routing mentioned, let alone vendor-specific such.
>>>
>>>   MUST be present. If the Vendor-Specific-Application-Id grouped AVP is
>>>        of the message. This field MUST be used as a secondary key field
>>> It seems to me that it would need to use vendor id *and* application 
>>> id to perform a proper lookup.
>>>
>>> Requested change:
>>>
>>> The solution is conceptually simple: make the routing table store 
>>> vendor id and application id and add text to 6.1.6 to take these 
>>> into account when routing requests.
>>>
>>> We now have two ways to identify the application of a request. 
>>> Either it has a "naked" Acct/Auth-Application-Id *or* it has a 
>>> grouped Vendor-Specific-Application-Id AVP where the Vendor-Id is 
>>> non-zero. Granted, the Diameter standard vendor is an important 
>>> special case but is it important enough to require a two-stage lookup?
>>>
>>> What do you think?
>>>

---

From: "Mark Jones" <[email-masked]>
Date: Wed, 10 Apr 2002 13:29:27 -0400

Hi Johan,

I agree that message routing as described in the latest draft does not take
into account vendor-specific applications.

If I've correctly understood the requested change, the Vendor-Id field would
be added to the Realm Routing Table Entry and if the Application-Id field
contains the identifier of a IETF standard application, the Vendor-ID field
MUST be set to zero (0).

I also agree with the change suggested in your editorial side-issue.

Regards,
       Mark

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Johan Johansson
> Sent: April 10, 2002 1:29 PM
> To: Johan Johansson
> Cc: [email-masked]; aaa-wg
> Subject: Re: [AAA-WG]: Message routing and vendor specific applications
>
>