Subject: [AAA-WG]: [Issue] Peer discovery mechanism requirements

From: Jari Arkko <[email-masked]>
Date: Wed, 02 Jan 2002 18:27:42 +0200

Submitter: Jari Arkko <[email-masked]>
Date: January 2, 2002
Reference: 
Document: BASE-08
Comment type: T
Priority: S 
Section: 5.2
Rationale/Explanation of issue:

Current text does not clearly enough specify
which peer discovery mechanisms are mandatory
and which are not.

There's two approaches to handling this issue.
One, (apparently the current approach) we stay
clear of using MUST/SHOULD/MAY in section 5.2
and therefore all of the text falls to Informative,
and nothing is really mandated.

The second approach is that we explicitly state
what DIAMETER nodes MUST/SHOULD/MAY be capable of
in this area. I favor the latter approach.

Proposed change:

Indicate in the list under 5.2 that the first
option (manual configuration) MUST be supported
by all DIAMETER nodes, while the latter two options
(SRVLOC and DNS SRV records) MAY be supported.

---

From: "Bob Kopacz" <[email-masked]>
Date: Thu, 10 Jan 2002 10:45:36 -0500

Hi,

I agree with the idea of not mandating server discovery.  

However there is a conflict between this issue and Pat's proposed
solution to issue#212, which would require server discovery.
(Maybe I should've sent this email to the issue#212 thread instead).

My understanding of the problem addressed by issue#212 is this:
Suppose a MN has been assigned a home agent in a foreign network, and
the MN migrates to a new FA.  The AAAH has no way to map the IP
address in the registration request to a Destination-Host AVP and
Destination-Realm AVP of the Home Agent.  The AAAH needs to know these
Destination-xxx AVPs so that the HAR may be routed to the correct
network (in case the MN has migrated to a new foreign network and
is retaining the HA allocated in the originally-visited network)
and to the specific HA.

Looking over the issue#212 thread, it seems that there are three
solutions to this problem (the following is lifted from various
emails):

1. Require that the AAAH perform the Server Discovery procedures in
   section 5.2 to determine the URL of the Home Agent.
    
   (This conflicts with Jari's new issue)

2. Create a new Mobile IP extension, and associated AVP, which the Mobile
   Node must include in its registration requests. This means that once the
   mobile has been initially registered by the HA, the HA would include its
   identity in the registration reply.

   (There was some support for this as being a better solution, but I
   think some felt this would take too long).

3. Require that the AAAH maintain session state, so that the identity
   of the HA is remembered.  I'm not sure if this even works, given
   that the later AMA may be delivered to a different AAAH.

   (But this conflicts with draft-mobileip-08, which
   indicates that the AAAH is not required to be session stateful).

Bob K.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Jari Arkko
> Sent: Wednesday, January 02, 2002 11:28 AM
> To: [email-masked]
> Subject: [AAA-WG]: [Issue] Peer discovery mechanism requirements
> 
> 
>

---

From: Jari Arkko <[email-masked]>
Date: Fri, 11 Jan 2002 12:09:54 +0200

Bob,

I can't say I'm that familiar with issue 212, but
you stated that one possible solution is for the AAAH to
perform the Server Discovery procedures. You also 
said that this has the problem that it is in conflict
with my proposed keywords, which do not require all
nodes to support the three discovery mechanisms.

Actually, I don't think this has to be a problem.
Base DIAMETER could require support for manual config
discovery, while MIP DIAMETER extension could require
more, such as both SRVLOC and DNS SRV.

Jari

---

From: "Bob Kopacz" <[email-masked]>
Date: Fri, 11 Jan 2002 08:25:02 -0500

Hi Jari,

> more, such as both SRVLOC and DNS SRV.

You're right.  I hadn't thought of this when blurting
out my comment when first looking over your new issue.

Bob K.