Subject: RE: [AAA-WG]: Issue 98: Peer role in Peer table?

From: "Martin Julien (ECE)" <[email-masked]>
Date: Fri, 27 Jul 2001 18:14:04 +0200

> hmmm.... now I'm really upset that I was convinced to remove 
> all of the
> verbage that I had originally proposed :(
> 
> See my comments below.
> 
> On Thu, Jul 26, 2001 at 10:31:29AM +0200, Martin Julien (ECE) wrote:
> > I guess that it suggests that the DRT should return a 
> > list of servers, which should be looked into to find out 
> > whether one of them is primary and available? If not,
> > then a secondary server is searched for. That means that 
> > load-balancing would occur only if several servers with 
> > the same role are defined for the DRT entry. Does that
> > mean that the Diameter node needs to make sure that
> > for all DRT entry, there is at least 2 servers available
> > all the time, I guess that is what it comes down to, right?
> 
> A peer could be marked as primary, but this isn't really necessary.
> A DRT lookup could return multiple servers, and if they aren't
> marked with any form of priority, then some mechanism should 
> be employed
> to determine which one should become primary. The same is done for
> the secondary. It is recommended that there be at least 2 possible
> servers for a given realm, but this isn't mandatory (of 
> course, without
> it you have no failover capabilities).
> 
> > 
> > That would mean that when a Peer becomes suspect, then the
> > DRT has to be looked into in order to find out which DRT
> > entry is affected in order to possibly initiate a new 
> > connection to another host?????
> 
> Well, that's why you typically want a secondary up and available.
> So, if you have a secondary connection, should the primary become
> suspicious, you can start sending messages to the secondary right
> away.
> 
> However, this is not a function of the routing table, but 
> rather of the
> peer table.
> 
> > Also, when receiving the Alternate-peer AVPs in the 
> > CER/CEA, should one of them be defined as secondary, while 
> > the others as alternate?, unless they are already defined 
> > as primary or secondary, of course. The reason for this
> > being that for routing based on Route-Record, Source-Route
> > and Destination-Host, I guess it would also be nice to 
> > have to same kind on feature, no?
> 
> well, perhaps the language here is mixed up. Alternates, as defined 
> in the CER/CEA is ONLY for server-initiated messages, and not for
> determining which peer is primary/secondary/alternate.

OK, let's move aside this primary/secondary/alternate question
and concentrate on the Alternate-Peer AVP thing.

So, if I understand correctly, this new AVP was introduced 
only for the purpose of the Source-Route AVP, am I right?

So, if I were an administrator of a Diameter proxy, then I
would have to configure the DRT so that messages are
routed based on realms to the next peer. If that peer
fails, messages would be forwarded to another server 
from the list defined in the DRT for that realm, right?
Of course, among the list of primary or secondary list
of servers...

When the answer is returned, and an agent of the list of
Route-Records is down, then it is impossible to route
the answer. That means that the originator of the request
should be expected to re-send the same message.

For server-initiated messages, if Destination-Realm and
Destination-Host is used, then the same scenario as before
in the last 2 par. is applied. 

For server-initiated messages, if the Source-Route AVPs
are used, then the administrator needs to configure for
the local node a possible list of Alternate-Peers, which
are probably a duplicate information of the list of
servers defined in the DRT entries of the surrounding
nodes, BTW. That is weird to me. Should all Alternate-Peers
be considered as secondary, since they would be used in
case the node fails? I guess yes. I still find this really
messy...maybe because it's friday...

Note that there should not exist alternates nodes defined 
for clients and servers, since
the Alternate-Peer AVP is not used to indicate redundant nodes. 
That means that Alternate-Peer AVP should not be used 
for servers and clients, as far as I understand. Otherwise,
I don't know why we should be restricted from using it for the
last HOP of the request as well, i.e. Destination-Host?

Here is an idea about the Alternate-Peer...

The thing is that with the Destination-Realm and Destination-Host
solution, the takeover node was handled by the DRT, which
was returning a list of servers. The only problem was that 
nothing could indicate a redundant server or client in the 
DRT, since that information should be stored in the Peer
table. I think it is an interesting feature, but different
then the original intention you had.

So, could't it be used for finding a redundant server or 
client host as well? 

I mean that I would prefer seeing clients and servers
use it when they support back-end redundancy between 2 hosts, 
e.g. a NAS 1 and NAS 2 are redundant in traffic, which means
that they would use the Alternate-Peer AVP to inform the other
nodes that they are considered as the same node. That would mean
that each node would have to support 2 host-Id. Otherwise, this
AVP should not be used for a client, neither for a Home server.

The same concept as the one described previously could also 
apply to routing the answers, based on Route-Record AVPs.

With that new definition, the Alternate-Peer could be renamed
Redundant-Peer AVP.

> 
> > So, as I see it, it is quite a lot of work to support this
> > concept of connections, from a point of view of a Diameter
> > agent and server, at least. Since I am not really sure
> > up to what point agents are expected to have openned 
> > connections, I am wondering if this is really something 
> > important for Diameter nodes?
> 
> Absolutely. However, if you prefer to not include any failover
> code in your implementation, then that's your perogative.
> 
> PatC
>

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 27 Jul 2001 09:30:17 -0700

Martin,

I believe that your comments below simply demonstrate that we shouldn't
have adopted a new scheme for server-initiated messages, and should have
relied on assuming that the configuration that is necessary for the
forwarding of messages towards the server needs to be correct.

sigh.

PatC