Subject: RE: [AAA-WG]: Comments on draft-mobileip-03

From: "Martin Julien (ECE)" <[email-masked]>
Date: Mon, 14 May 2001 16:59:30 +0200

> > > > 3) The problem with the previous comment, is that the 
> > > MIP-Previous-FA-FQDN
> > > > does not represent the realm of the previous domain, only 
> > > the FQDN of the
> > > > FA, which might be only routable by the AAAF, right? I am 
> > > not sure that
> > > > the discussion we had on the mailing list a while ago 
> > > suggested that the
> > > > FQDN (let's say ABC.com) was the realm plus another name 
> > > > (let's MACHINE1.ABC.com). That does not make sense to me at 
> > > least. If it
> > > > would have been like that, I would argue that we do not 
> need two 
> > > > destination FQDN and Realm.
> > > 
> > > It is, and the reason why we have two separate AVPs is to 
> > > reduce the amount
> > > of work done on proxies. This has been done in RADIUS via 
> > > some vendor-specific
> > > AVPs, because otherwise each proxy must extract the FQDN, and 
> > > retrieve the
> > > Realm. Not alot of work, but very repetitive, so let's 
> save some CPU
> > > cycles while we can.
> > > 
> > > And, btw, if we only had the Destination-FQDN,  it 
> wouldimplies that a
> > > message would have to be sent to a specific Diameter entity, not
> > > any one in a given domain.
> > 
> > My understanding was that the FQDN can be also a machine on 
> a different 
> > domain then the one publish by the proxy. I mean that the 
> back-end of the
> > proxy could connect to several internal domains, which are 
> not related 
> > at all with the one of the proxy. Let's say I have some 
> servers within 
> > my corporate network defined in one domain (ABC.COM), while my proxy
> > domain shows another one (ACME.COM). I was not expecting the servers
> > on my corporate network to be defined as DIA1.ACME.COM. Also, I 
> > assume that it would not be allowed to define an FQDN for my 
> > corporate servers like DIA1.net1.ACME.COM, for the case you are 
> > referring to, right?
> 
> The Destination-FQDN is the *final* target for a message. If 
> your proxy
> has a different domain than your home server, that's fine. When the 
> routing path is setup with your partners, you simply tell 
> them that any
> messages for *.ABC.COM go through ACME.COM. This is straight forward 
> proxying.
> 
> However, ther must be a way to encode the target Diameter 
> host, if one is
> needed. There are applications where this is useful (e.g. get 
> the HAR to
> the right Home Agent, perhaps through proxies in a visited network).

Exactly. I would assume that HA must be identified in the AAAH as 
a Realm and FQDN, not only FQDN. The FQDN is only used for the last
hop, not for routing through proxy servers.

> As far as server naming, you can call it whatever you like. However,
> if it isn't a real FQDN that one uses with DNS, then there is 
> NO possibility
> for dynamic discovery.

I guess that the proxy owning the domain ("Realm") is the only one worried
about the server discovery within its own domain. That is easy to 
support. However, my point is that there might be no naming convention
at all between the FQDN and the Realm, which would make the 
MIP-Previous-FA-FQDN AVP completely useless in the AAAH without a
corresponding Realm. I would prefer having only a 
MIP-Previous-FA-Realm AVP instead of a MIP-Previous-FA-FQDN AVP.

Anyway, is it still used in the new Mobile-IP draft? Since the AAAH
always needs to be contacted, I guess it would know in which domain
the MN is located and where it is roaming, based on the Origin-Realm
of the AMR.

Thanks!
/Martin

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 14 May 2001 08:13:44 -0700

> hop, not for routing through proxy servers.

just to make sure that we are on the same page, FQDN is:

	host.realm

So, yes, both the Destination-FQDN and the Destination-Realm would ne
required in the HAR.

> MIP-Previous-FA-Realm AVP instead of a MIP-Previous-FA-FQDN AVP.

I prefer as much information as possible, and the ream can be extracted
from the fqdn, if that is necessary. Since this isn't needed on each hop,
for processing purposes, i would prefer to leave it as-is.

others?

> the MN is located and where it is roaming, based on the Origin-Realm

In the event that you have multiple AAAHs in the home network, and
state isn't replicated, it would be nice to allow for this information to
be supplied.

PatC