IETF Logo Mail Archive

Re: [Dime] Review of draft-ietf-dime-realm-based-redirect-03

<lionel.morand@orange-ftgroup.com> Tue, 17 August 2010 10:42 UTC

Return-Path: <lionel.morand@orange-ftgroup.com>
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C9A93A687C for <dime@core3.amsl.com>; Tue, 17 Aug 2010 03:42:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.073
X-Spam-Level:
X-Spam-Status: No, score=-102.073 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdkNdyMr2yW4 for <dime@core3.amsl.com>; Tue, 17 Aug 2010 03:42:07 -0700 (PDT)
Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id C9E1C3A68DB for <dime@ietf.org>; Tue, 17 Aug 2010 03:42:06 -0700 (PDT)
Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 834926C0003; Tue, 17 Aug 2010 12:42:56 +0200 (CEST)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 728EF6C0002; Tue, 17 Aug 2010 12:42:56 +0200 (CEST)
Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Aug 2010 12:42:41 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB3DF8.EA9F35F4"
Date: Tue, 17 Aug 2010 12:42:40 +0200
Message-ID: <D109C8C97C15294495117745780657AE0CC0E810@ftrdmel1>
In-Reply-To: <023B0737-0E8B-4A68-80ED-EC79767DFB92@bridgewatersystems.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Dime] Review of draft-ietf-dime-realm-based-redirect-03
Thread-Index: Acs9h7L7fQ4frSo7SE275BlzcVuCewAbhrRA
References: <3052C5CA-B52F-4DB2-B04A-D32110134CAC@gmail.com> <02AE8F14-B61F-4EAF-8654-7B86F154A9C8@huawei.com> <1FD363A7-3530-4F5F-8F17-0B0A861C33D4@bridgewatersystems.com> <000001cb3d23$4be946c0$e3bbd440$@net> <023B0737-0E8B-4A68-80ED-EC79767DFB92@bridgewatersystems.com>
From: lionel.morand@orange-ftgroup.com
To: avi@bridgewatersystems.com, gwz@net-zen.net
X-OriginalArrivalTime: 17 Aug 2010 10:42:41.0022 (UTC) FILETIME=[EAC601E0:01CB3DF8]
Cc: draft-ietf-dime-realm-based-redirect@tools.ietf.org, dime@ietf.org, dime-chairs@tools.ietf.org
Subject: Re: [Dime] Review of draft-ietf-dime-realm-based-redirect-03
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Aug 2010 10:42:08 -0000

Hi Avi,
 
If I'm correct, you are not sending a request TO a Redirect Agent but you are receiving an answer FROM a Redirect Agent.
Before receiving the answer with the Result-Code set to DIAMETER_REDIRECT_INDICATION, the Diameter agent only knows that it is sending the request to a Diameter agent advertizing the Relay application, which could be a Relay or a Redirect agent.
 
Why should the request originator have to know the redirection mechanism (host-based or Realm-based) supported by a possible redirect agent in the path?
Does it not have to rely only on the redirection information provided in the answer to know where to resend the request?
And if the request is for the Diameter X appl that supports the Realm-based redirection, it will be able to handle the specific realm-based info sent back by the Redirect Agent.
 
Regards,
 
Lionel
 


________________________________

	De : Avi Lior [mailto:avi@bridgewatersystems.com] 
	Envoyé : lundi 16 août 2010 23:12
	À : Glen Zorn
	Cc : dime@ietf.org; draft-ietf-dime-realm-based-redirect@tools.ietf.org; dime-chairs@tools.ietf.org
	Objet : Re: [Dime] Review of draft-ietf-dime-realm-based-redirect-03
	
	

	On 16-08-2010, at 05:13 , Glen Zorn wrote:


		
		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.
		
		If the change in behavior is backward-compatible, why not?


	Its not just sufficient to know that an added feature is backwards compatible.

	The "approach" taken in Diameter design is that the one entity knows the behavior/capability of a particular another entity.  If you simply add functionality to something how would I know that the new features that i want to use are supported.

	Specifically, how do I know that when I forward a message to a Redirect Agent that I would be able to get realm-redirections.  If I have two relay agents how would I know which one to use. 

	We have to decide that we are okay with building functionality into entities without having the ability to know whether those entities support those features.  And if we are okay with that then that is great.

	 The draft solves the problem one way -- it allows the Redirect Agent know whether an Application can handle the new redirect attributes.  How about the other way as well?
	

	
	
	Avi Lior
	avi@bridgewatersystems.com
	office: +1 613-591-9104x6417
	    cell: +1 613-796-4183

v2.23.0 | Report a Bug | By Email