Subject: [Dime] Proposed changes to draft-ietf-dime-realm-based-redirection (2)

From: Tom Taylor <[email-masked]>
Date: Mon, 4 Apr 2011 22:06:53 -0400

Avi Lior had the following comment, received 11/08/2010 (ET). By the 
way, my charts at the meeting said the comments were received last 
October. I don't know what strange process caused me to transpose year 
and month, but I apologize for the misdirection.

<Begin comment>

Hi,

I have reviewed draft-ietf-dime-realm-based-redirect-03 document -- or I 
should say i started but I had to stop because there are serious 
fundamental issues with this draft.

I should start with the fact that i think the problem statement raised 
by the draft is valid. Also, I think that Diameter base 3588 should have 
supported Realm based redirection as well as host based redirection. 
Actually Realm-based redirection are probably more useful.

However, the problem I am having is that the draft is changing the 
semantics of a Redirect Agent as defined by base and I dont think that 
we should be allowed to do that.

I get that the draft got around backwards capability issue surrounding 
the new AVPs be introduced by asserting that only new applications will 
support the attributes.

But in order to deliver this feature in 3588 the behavior of the 
Redirect Agent had to change.

This new redirect agent has to differentiate between applications that 
do support realm base redirection vs non-realmbased redirection.

This is new base behavior and thus should be done in Diameter V2

There is an alternative - which i thought was the approach taken when i 
started to read the draft and that is:

-let the Application itself perform the redirection.  To use the example 
provided, if the operator does not want to host the application anymore, 
it can let the Application respond back with the realm and/host 
redirection attributes.

<end comment>

As I mentioned in my previous note, I now agree with Avi. The conversion 
comes about through a chance reading of the following paragraph in 
Section 2.4 of RFC 3588:

    Relay and redirect agents MUST advertise the Relay Application
    Identifier, while all other Diameter nodes MUST advertise locally
    supported applications.  The receiver of a Capabilities Exchange
    message advertising Relay service MUST assume that the sender
    supports all current and future applications.

I am worried that, by specifying new behaviour for conforming redirect 
agents, we are setting a precedent that could lead to trouble if it is 
followed. Since the normal application negotiation process is 
short-circuited in the case of nodes offering the Relay service, the 
forwarding agent becomes unable to predict the behaviour of Relay nodes. 
Without careful Working Group scrutiny, a specification involving the 
Relay service could end up breaking something. This is brittle. It is 
safer to place such behaviour at the application level, as Avi suggests.

Based on that, the basic change required in the realm-based-redirection 
draft is to change "relay agent" to "proxy" wherever it occurs. 
Naturally, other details are also affected. Here is the list of detailed 
changes that are required.

Abstract:

  Delete the first sentence and the word "However" at the beginning of
  the next sentence.

Introduction, first paragraph, fourth sentence:
- Replace "redirect server" by "service", so that the sentence reads:

    ... the original operator maintains a service to
    indicate the alternative destination

Section 2:
- Change to read as follows:

    Because realm-based redirection is not part of base Diameter
    behaviour, support for realm-based redirection has to be
    provided at the application level by a Diameter proxy.
    Designers of new applications wishing to include support
    for realm-based redirection can incorporate the mechanism
    specified here by reference to this document.

Section 3.1.1:
- Change the title to: "Behaviour at the Redirecting Proxy"

- Replace the two paragraphs preceding the bullets with the
   following text:

    If a Diameter proxy that supports realm-based redirection
    receives a request for an application that includes
    realm-based redirection, and the proxy has been configured
    to provide redirection for the destination realm of the
    request, then:

    [Bullets follow, including the new one proposed in my
    previous message]

- Change all instances of "redirect agent" in the bullets
   to "redirecting proxy".

- Change the final bullet (in which redirection is performed)
   to read as follows. The first sentence is unchanged but is
   included for context.

    o  Otherwise, if an application supporting the use of realm-based
       redirection was negotiated with the peer, the redirect agent MUST
       set the Result-Code AVP to DIAMETER_REALM_REDIRECT_INDICATION
       rather than DIAMETER_REDIRECT_INDICATION.  Furthermore, the
       redirect agent MUST include a Redirect-Realm AVP containing the
       realm with which it has been configured for the purpose of
       realm-based redirection for this application in its answer
       message. The redirecting proxy MUST maintain the Hop-by-Hop
       Identifier in the message header, so that the agent from
       which it received the request can retrieve that request from
       its pending message queue (see Section 5.3 of RFC 3588).

QUESTION: should the redirected message have the 'E' bit set?

Tom Taylor

---

From: Sebastien Decugis <[email-masked]>
Date: Thu, 07 Apr 2011 16:14:19 +0900

Hi Tom, all,

> by the draft is valid. Also, I think that Diameter base 3588 should 
> have supported Realm based redirection as well as host based 
> redirection. Actually Realm-based redirection are probably more useful.

I strongly agree with this.

> we should be allowed to do that.

I must confess I have difficulties seeing what the problem is in this 
case; either the redirect agent would support this feature, or it would 
not. Both cases end up in being handled correctly, I think.

> This is new base behavior and thus should be done in Diameter V2
Agreed also.

> There is an alternative - which i thought was the approach taken when 
> i started to read the draft and that is:
>
> -let the Application itself perform the redirection.  To use the 
> example provided, if the operator does not want to host the 
> application anymore, it can let the Application respond back with the 
> realm and/host redirection attributes.

I agree this solves the issue of the Redirect Agent being "aware" of 
this new mechanism. However, it seems to me that the feature should be 
kept transversal to the applications, i.e. that the peer that handles 
these realm redirect should not need any knowledge of the application(s).

> forwarding agent becomes unable to predict the behaviour of Relay 
> nodes. Without careful Working Group scrutiny, a specification 
> involving the Relay service could end up breaking something. This is 
> brittle. It is safer to place such behaviour at the application level, 
> as Avi suggests.
Another approach would be for example to include an AVP in the CER/CEA 
exchange to signal that Realm-based redirect is supported by a relay. 
But I still believe that there is no real problem if the relay agent 
does not support the realm-based redirection...

> QUESTION: should the redirected message have the 'E' bit set?
If the features becomes simply part of the "normal" application flow, 
and realm-based redirect is handled by proxies of this application, I 
think the E bit should be cleared, since "standard" based protocol 
agents will not have to deal differently with these answer messages in 
that case.

Best regards,
Sebastien.

---

From: Tom Taylor <[email-masked]>
Date: Thu, 21 Apr 2011 10:00:19 -0400

Avi was the only one who had this concern (I don't really count). 
Chairs, can you confirm a consensus that we can leave it up to the 
Redirect Agent to do the redirection?

And should I prepare text to implement this in 3588bis?

On 04/04/2011 10:06 PM, Tom Taylor wrote:
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>
>