Re: [Dime] endpoint determination

Jouni Korhonen <jouni.nospam@gmail.com> Thu, 28 November 2013 12:24 UTC

Return-Path: <jouni.nospam@gmail.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524011AE0E8 for <dime@ietfa.amsl.com>; Thu, 28 Nov 2013 04:24:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52T5qWcz88Ha for <dime@ietfa.amsl.com>; Thu, 28 Nov 2013 04:24:22 -0800 (PST)
Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A6D331AE0E7 for <dime@ietf.org>; Thu, 28 Nov 2013 04:24:21 -0800 (PST)
Received: by mail-bk0-f47.google.com with SMTP id mx12so3788208bkb.34 for <dime@ietf.org>; Thu, 28 Nov 2013 04:24:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=bHlvQZWkjwinGmpif6XOjOrXKyNoRFfj4SivZmjcgdg=; b=S2y9CH0kaleB66s6Z1H4ALRZWuaYhT/V2LXUKWv/G10CtM6YFiS0bytvWCBjw7KkVn vyBuj9iLGeLjFiDYwNdKuL5vWy1LiVjNrfq3LUm/STervelZiXEBUhwu05nGS9dIfTse QEFeWn5DyOALcJmSY4RR2+YmjpY4ezFFlB+duHndldJhMTKIHrElxzm4dJFUYEeTxsn4 99cWSWBNlsEoScbQH3X2jDn9Qn6uxvgwEAaXBRIn95A6PDFced5Jssbz6OZ+XodJv7qp UteRwCcOHzgTSJTbKWMPz70Me0b2Wu7CTdumTeJQLkUWdmYpmtgeBl2lTBOWFmopC2hi 4jlA==
X-Received: by 10.205.47.132 with SMTP id us4mr1694480bkb.27.1385641460101; Thu, 28 Nov 2013 04:24:20 -0800 (PST)
Received: from ?IPv6:2001:6e8:480:60:5c30:8d03:a3e0:16fc? ([2001:6e8:480:60:5c30:8d03:a3e0:16fc]) by mx.google.com with ESMTPSA id qg7sm59357357bkb.6.2013.11.28.04.24.17 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Nov 2013 04:24:17 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen <jouni.nospam@gmail.com>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519BD77@DEMUMBX014.nsn-intra.net>
Date: Thu, 28 Nov 2013 14:24:16 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <F00E3FBA-DBC9-4392-8C47-81C97EAC9CE0@gmail.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519BD77@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>, "dime@ietf.org list" <dime@ietf.org>
X-Mailer: Apple Mail (2.1510)
Subject: Re: [Dime] endpoint determination
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Thu, 28 Nov 2013 12:24:24 -0000

Just a generic note.. If and when you do more detailed reading, please use to latest online working copy:
https://github.com/jounikor/draft-docdt-dime-ovli/blob/master/draft-ietf-dime-ovli-01.txt

- Jouni


On Nov 28, 2013, at 2:21 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

> Hi,
> 
> draft-ietf-dime-ovli-00 in Clause 5.1 says:
> 
> How the endpoints are determined is specific to a deployment, a Diameter node role in that deployment and local configuration.
> 
> 
> In order to better address REQ  6 of RFC 7068 I would like to propose some principles that should be taken into account:
> 
> 1. A client that supports the Diameter Overload Control Mechanism must (offer to) take the role of a reacting endpoint and hence includes the OC-Feature-Vector AVP when sending requests.
> 2. An Agent that - based on local configuration - takes the role of a reporting endpoint (towards the downstream reacting endpoint) must also (offer to) take the role of a reacting endpoint towards the server and hence replace the received OC-Feature-Vector AVP with its own OC-Featur-Vector AVP.
> 3. An agent that supports the Diameter Overload Control Mechanism and that - based on absence of local configuration - does not take the role of a reporting endpoint must be able to detect whether a downstream agent or client  already takes the role of the reacting endpoint (e.g. by checking the presence of an OC-Feature-Vector AVP in the received request). If it detects that no downstream node took the role of the reacting  endpoint, the agent must take the role of the reacting endpoint and hence insert an OC-Feature AVP to the request. I.e. determination of the reporting endpoint is done dynamically and does not rely on local configuration.
> 
> Comments are welcome.
> 
> Ulrich
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime