Subject: RE: [AAA-WG]: [AAA-WG][issue]: Realm Routing Table and section 6.1

From: <[email-masked]>
Date: Tue, 7 May 2002 03:02:55 +0300

Hi Julien,

Section 6.1 is a general recommendation section.  I think that some
implementation flexibility can be used.  I think that the text in 6.1
is good, I would not want to make the text any more tight.

I don't see any interoperability issues here - so I think that
no changes are needed.

John

> We have section 6.1:
> "
>   When a message is received, the message is processed in the 
> following
>    order:
>       1. If the message is destined for the local host, the procedures
>          listed in section 6.1.4 are followed.
>       2. If the message is intended for a Diameter peer with whom the
>          local host is able to directly communicate, the procedures
>          listed in section 6.1.5 are followed. This is known as Request
>          Forwarding.
>       3. The procedures listed in section 6.1.6 are followed, which is
>          known as Request Routing.
>       4. If none of the above is successful, an answer is returned with
>          the Result-Code set to DIAMETER_UNABLE_TO_DELIVER.
> "
> 
> Concerning 2.:
> 
> Maybe it could be nice to have a clear definiton of "a Diameter peer with whom
> the local host is able to directly communicate". Is it only a peer in the
> Diameter Peer table ?
>
> Concerning 3.:
> 
> We must follow section 6.1.6
> 
> Section 6.1.6:
> "
> 6.1.6  Request Routing
> 
>    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).
> "
> 
> It appears that the only case for which we must use the Realm 
> Routing Table
> not need LOCAL action. So is it useful to have this action in 
> the Realm Routing
> Table ?
> 
> May I miss something ?
> 
> 
> 
> 
>