Subject: RE: [AAA-WG]: Date: Mon, 23 Apr 2001 11:02:13 +0200

From: Patrice Calhoun <[email-masked]>
Date: Wed, 25 Apr 2001 06:42:35 -0700 (PDT)

> > > To understand the hole
> > > thing, one should go to both sections, so I suggest to 
> > merge them.  In that
> > > way, it would be clearer. E.g. it is weird to see 
> > Destination-FQDN and
> > > Destination-Realm AVP stated one in section 5.3, and the 
> > other in 12.4.7
> > 
> > So the Destination-FQDN is used in the message forwarding 
> > code, while the
> > Destination-Realm is used for forwarding purposes.
> > 
> Does this means that Destination-FQDN is used just to forward
> the message to last hop when being in Home domain, and that
> Destination-Realm is used for routing ?

That is correct. 

> I don't see the difference between "message forwarding code"
> and "forwarding purposes".

ok, let me try again (and perhaps if others are confused, it means additional
text is required in the spec).

You essentially have two separate tables; peers and routes.

The peers table is a list of all known peers that you communicate with. For
each one of these peers, you invoke the peer state machine. When a packet is
received that has a Destination-FQDN, you look at that AVP to see if the peer
in the AVP is in your table, and if so, you forward the message directly to
that peer.

The routes table contains a list of realms, and all peers that support that
realm. You could also have a default realm, but this is really an
implementation detail. When a packet is received, and the peer in the
Destination-FQDN AVP is unknown, the realm in the Destination-Realm AVP is
looked up in the routes table, and the packet is routed. of course, if no
route is found, a DSI even is returned with the appropriate error set, and
hope that the downstream server will forward the request to another server
that can support the request.

Back to forwarding. You may ask why there are two separate procedures. Well,
it is quite simple. If the Destination-Realm AVP was always used, then when a
route is found, the message would be sent to one of the many peers that
support the realm, when in fact the message had a very specific target host.

That is the main difference, and why you need separate lookup procedures.

> > > Section 5.3 Destination-FQDN AVP
> > 
> > > Should instead, state: "This AVP MUST be present in all 
> > unsolicited server
> > > initiated  messages, all reply and all answer messages." 
> > See example in
> > > section 12.1 
> > 
> > I could modify the figure to include the AVP in the request, 
> > but it is not
> > mandatory to be present when the client doesn't care which 
> > server handles the
> > request.
> > 
> 
> I just wanted the text to clearly state that Destination-FQDN MUST be 
> present as well in Answer and Response messages (nothing about
> Requests), no just only in Indications.

ok, sorry I missed your point ( but reading above, I see it was actually quite
clear the first time around :(

> > > I miss as well how the Response is routed back to the Diameter
> > > client (which is not present in the drawing, and it will 
> > made it clearer, as
> > > DI1 is not the originator of the message, but the first proxy). With
> > > Destination-FQDN set to DIA1, how the response can reach 
> > the client ?
> > 
> > DIA1 *is* the client. The client's FQDN is in the 
> > Destination-FQDN AVP.
> 
> I don't understand that DIA1 is the client, as the text says: "Figure 2
> depicts an example where DIA1 receives a request to authenticate user ...
> DIA1 looks up "abs.com" in its local realm route and ....
> So, DIA1 is the first proxy in the chain, but not the client, as it receives
> a RQ from someone else, right?

ok, looks like some of the text surrounding the figure needs to be modified to
match the figure.

> > > Section 12.2Proxy and Redirect Server handling of requests
> > 
> > No because the presence of the Destionation-Realm implies 
> > that the message is
> > routable. There are many cases where that is not the case 
> > (again, DRI, DSI and
> > the watchdog messages are examples).
> 
> Then, in table 16.1 for DRI and DSI, Destination-Realm should be 0 ?

correct.

> > > Section 12.4  Proxy Server
> > > 
> > > Say instead:  Maintaining transaction state implies that a 
> > server keeps a 
> > >       copy of a request or query which is then used when 
> > the corresponding
> > > response is
> > >    received.
> > 
> > You are proposing just removing text?
> 
> No, just add "query" to the sentence.

Ah, ok.

> > >    A stateless proxy is one that does not maintain session 
> > state, but
> > >    MUST maintain transaction state. Transaction state 
> > SHOULD be released
> > >    after a request's corresponding response has been 
> > forwarded towards
> > >    the recipient, and has been acknowledged by the 
> > underlying transport.
> > > Isn't it strange to call a proxy which keeps transaction 
> > state "stateless"?
> > 
> > Yes perhaps, but a minimal amount of state is unavoidable :(
> 
> This was exactly my point.
> 
> 
> > You mean in addition to 
> > 
> > " A stateless proxy is one that does not maintain session 
> > state, but MUST
> > maintain transaction state. Transaction state SHOULD be 
> > released after a
> > request's corresponding response has been forwarded towards 
> > the recipient,
> > and has been acknowledged by the underlying transport."
> > 
> > ?
> 
> I was suggesting to add something as "A stateless proxy is also the one that
> upon receipt of a Request/Query keeps the Hop-by-Hop identifier, and restore
> it to its original value after receiving the corresponding Answer/Response.
> Furthermore, a stateless proxy MAY also add a Proxy-State AVP for
> Request/Query and MUST remove it when receiving a message targeted to the
> Diameter local server.

ok, just add additional clarification. That sounds reasonable.

PatC

---

From: "Yolanda Garcia-Serrano (ECE)" <[email-masked]>
Date: Wed, 25 Apr 2001 10:31:08 +0200

Hi, Pat
Thanks a lot for your answers.
See inlined still some doubts/comments.

BR
	/Yolanda García

I was suggesting to add something as "A stateless proxy is also the one that
upon receipt of a Request/Query keeps the Hop-by-Hop identifier, and restore
it to its original value after receiving the corresponding Answer/Response.
Furthermore, a stateless proxy MAY also add a Proxy-State AVP for Request/Query
and MUST remove it when receiving a message targeted to the Diameter local server.

> Thanks for the great comments!
> PatC

It's nice try to modestly contribute to reach a better spec.
Thanks to you.
Yolanda