Subject: [AAA-WG]: Remove support for Source-Route

From: Pat Calhoun <[email-masked]>
Date: Mon, 6 Aug 2001 01:53:12 -0700

Submitter name: Pat Calhoun
Submitter email address: [email-masked]
Date first submitted: August 6th, 2001
Reference: 
Document: NASREQ 07
Comment type: T
Priority: S
Section: 
Rationale/Explanation of issue: 
Support for explicit paths for server-initiated messages was added in
-07. Discussions I have had with folks this week show that consensus
is that this feature is overly complex, and we should instead require
that the network is configured properly.

Requested change: 
Go back to -06 way of server initiated messages.

---

From: Jacques Caron <[email-masked]>
Date: Mon, 06 Aug 2001 23:36:48 +0200

Hi,

I don't quite see how it is so complex. It is nothing more than 
Destination-Host extended to all intermediate nodes, with backup 
(Alternate-Host). Actually, we should remove Destination-Host :-)

If properly integrated in the text of 6.1, it will appear as natural as the 
Destination-Host routing.

Jacques.

>Go back to -06 way of server initiated messages.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 7 Aug 2001 01:38:54 -0700

Conversations I've had with numerous folks is that configuration for
the reverse direction should be required, and they see no need to 
have a Source-Route mechanism. Furthermore, having the Alternate-Peer
to handle the case where a box is no longer reachable, is rather
complex. If configuration alone was used, and a box became unreachable,
normal Diameter routing would ensure that the packet was sent to its
destination.

PatC

---

From: Jacques Caron <[email-masked]>
Date: Tue, 07 Aug 2001 11:02:00 +0200

Hi,

The issues I see with using realms on the way back are:

1. Overloading of "realms". For me, realms contain users (name@realm), not 
devices (name.realm). Hence, a server might handle a realm for users, and 
be part of a different "domain". Or vice-versa.

2. If there are provisions for making sure subsequent messages are routed 
to the same server, I don't see why we shouldn't have the same thing for 
intermediate proxies (in both directions).

This being said, I think it is quite easy to replace the Destination-Host 
routing with source route (more or less, 
:g/Destination-Host/s//Source-Route/g + removing the last Source-Route AVP 
in the list before forwarding). Do that, and you will see it is really not 
that complex at all.

Also, we could remove support for Alternate-Peer (or make that optional), 
and fallback to "regular" routing when a host on the path is unreachable 
(then of course it will work only if appropriate routing info is present).

Personally, I like very much the idea that the first request in a session 
"discovers" the path to the home server, and then all subsequent messages 
in that session, in both directions, all follow the same path until broken. 
I'm not a fan of proxies that require this, but I have this strange feeling 
that we will definitely need it and will be very sorry if we don't include 
support for that in some way.

But I guess most of the others don't agree with me :-(

Jacques.

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 7 Aug 2001 02:29:51 -0700

> in the list before forwarding). Do that, and you will see it is really not 

There is a fundamental difference between Source-Route and Destination-Host.
The latter is used to ensure that a message can be predictably sent to the
*final* Diameter node. The former is used to ensure that the path can be
enforced, modulo the fact that some of nodes encoded in the route encoded
may not be reachable, and therefore alternates must be advertised.

INHO, there is an order of magnitude of complexity in complexity between
the two, and we need to really understand whether the complexity is warranted.
Of the folks that I've heard from, they didn't think this feature was all
that useful, and configuration would be sufficient.

> (then of course it will work only if appropriate routing info is present).

but encoding a route will not work if a node in the route fails. Normal
routing works great in the typical case because the message will be routed
regardless of any unavailable nodes in the network. However, if a route is
stated, and one of the nodes in the path is not accessible, then the message
would not be delivered.

So there is a clear difference.

> support for that in some way.

You may be right, but if we provide the framework to support this, it certainly
will be used. Otherwise, it will most likely not. 

> But I guess most of the others don't agree with me :-(

only on this one particular issue :)

PatC