Subject: [AAA-WG]: [Issue] Routing/forwarding clarifications

From: Jacques Caron <[email-masked]>
Date: Thu, 14 Jun 2001 18:29:10 +0200

Submitter name: Jacques Caron
Submitter email address: [email-masked]
Date first submitted: 14-Jun-2001
Reference:
Document: Base
Comment type: T
Priority: 1
Section: throughout
Rationale/Explanation of issue:

- If multiple hosts listed for a given realm (redirect, relay, proxy), use 
the same one for a given Session (either need to maintain Session state or 
to use some hash function based on Session-ID) unless error occurs (and 
then keep that one that works).
- Clarify if connections to peers are supposed to be opened at startup, or 
when needed only.
- Clarify relationship of server discovery (SLP, DNS A, DNS SRV...) with 
peer table and/or routing table.
- move peer and routing table description earlier in the doc (somewhere in 
2.5 or 2.6).
- Clarify whether "on-demand" connections (e.g. Redirect-Host with 
certificate) should timeout.
- refuse connection to oneself

Jacques.

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

---

From: Jacques Caron <[email-masked]>
Date: Sat, 16 Jun 2001 13:36:08 +0200

Hi,

The following points need to be discussed before text can be proposed:

I would say at startup (so that the agent knows immediately if peers are up 
or down when a request needs to be sent, and to avoid long connection 
establishment -and thus forwarding- delays).

On the other hand, a roaming consortium proxy might not want to keep 
hundreds of sessions up all the time. An aggregator proxy might not want to 
keep connections to each and every access device it serves all the time 
either (some access devices might have very low usage?).

It's probably best to make it an administrative option?

The issue is to know if the use of any of the "server discovery" methods 
(DNS, SLP...) is an extension to the routing table (map a realm to a peer, 
but the peer must already be in our peer table), or to the routing AND peer 
table (map a realm to a peer created on the fly), or just to the peer table.

At least in the case of DNS, I think it's the former, but maybe people have 
reasons to believe otherwise? And in the case of SLP, I have no idea, not 
fluent with that one yet :-( Probably the second or third, but then 
shouldn't there be things like realms in the service template in Appendix A?

In the first case, what if DNS resolves to a peer we don't have in our peer 
table?

In the second and third case, what about security associations (can you put 
a certificate in DNS?)

This also applies to DNS/SLP-discovered servers, and if connections are 
established when needed only (cf first issue above). At the moment, we 
actually force all connections to stay established using the Watchdog 
messages, if I'm not mistaken?

Let me know what you think so I can propose some text. I will also include 
some text for the rest of the items.

Thanks,

Jacques.