Subject: RE: [AAA-WG]: Comments on draft-ietf-aaa-diameter-mobileip-02.txt

From: "Rambabu Tummala" <[email-masked]>
Date: Fri, 27 Apr 2001 11:36:49 -0500

Pat,
Thanks for the explanation.

Rambabu Tummala
Nortel Networks
ESN 444-8970
External (972)684-8970

-----Original Message-----
From: Pat Calhoun [mailto:[email-masked]]
Sent: Friday, April 27, 2001 11:04 AM
To: Tummala, Rambabu [RICH1:IP35:EXCH]
Cc: 'Patrice Calhoun'; 'Tony Johansson'; [email-masked]
Subject: Re: [AAA-WG]: Comments on
draft-ietf-aaa-diameter-mobileip-02.txt

On Fri, Apr 27, 2001 at 10:26:11AM -0500, Rambabu Tummala wrote:
> > The base protocol is pretty clear in that responses and answers are
> proxied
> > using the Route-Record AVP, not the Destination-Realm AVP.
> 
> I agree it is compliant with base protocol specification.  I guess my
> question then would be how does the response reach the originator of the
> requestor if one of the proxies fail before the response goes through.  
> 
> I guess, I would like to see the text in section 12.4.2 of
> draft-ietf-aaa-diameter-02.txt change from "MUST" to "Should".
> 
> If we remove this restriction it gives flexibility to the protocol.

I agree, and a previous version of the base protocol did in fact allow
for the reverse path to be different from the forwarding path. However,
concensus on the mailing list was that this was not really a feature that
was required, since it introduced too much complexity. 

So the way it currently works is that if a response isn't received because
of a network or host failure, the original request will be resent either
by the NAS, or by a proxy, as specified in the failover text in the base
draft.

> 
> May be there are reasons behind specifying this way. Please enlighten me.

As I mentioned above, the WG believed that the complexity introduced by
supporting such a feature didn't warrant supporting this feature.
Furthermore,
there are proxies that maintain state, and not knowing whether a response
will traverse a particular proxy makes this very difficult.

Hope this helps,

PatC