Re: [Dime] endpoint determination

Jouni Korhonen <jouni.nospam@gmail.com> Wed, 04 December 2013 14:27 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 775561ACB4E for <dime@ietfa.amsl.com>; Wed, 4 Dec 2013 06:27:45 -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 XEobjswV6cqR for <dime@ietfa.amsl.com>; Wed, 4 Dec 2013 06:27:43 -0800 (PST)
Received: from mail-bk0-x232.google.com (mail-bk0-x232.google.com [IPv6:2a00:1450:4008:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 16FC61AC4C1 for <dime@ietf.org>; Wed, 4 Dec 2013 06:27:42 -0800 (PST)
Received: by mail-bk0-f50.google.com with SMTP id e11so6637209bkh.37 for <dime@ietf.org>; Wed, 04 Dec 2013 06:27:38 -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:cc :content-transfer-encoding:message-id:references:to; bh=Bd5BKoj4f7kYrQjB4wQ82SnjF5zXOpQA7iHAIELyHbE=; b=cENuepvkVhYAgFzc8mgiz/15EIyKppSxjKlZSLn1QfgQ7yFHTDDV8acCYEXPOe1aak /kUVXpkIdcZats7uxmIkFSUHJJVsbT8fZrqCP/KBw7jd6jziDgKiqgURvUEHJ7RFL7kA JAunnR3ePp4vTOpQvmbWZGBB4nj9TkhyfanGVCQBz0Y7OIo28E7ZEd3sWSm3hmLNagdY aBTnSnDPNsJsxn0hDZJiyy7vtem0b61lTzooIOwDJyaYYbJpUpv6xcwgmrTq/9pH+rEq s8KfNlWKKMSbUhTDuyhF042eOLDSE7G8pDX6n/vWiQ8YglWhQtZDynVH/ZUezvXNAFhI 5cCg==
X-Received: by 10.205.97.69 with SMTP id cj5mr38419bkc.132.1386167258553; Wed, 04 Dec 2013 06:27:38 -0800 (PST)
Received: from ?IPv6:2001:6e8:480:60:787f:3bfd:4b90:9728? ([2001:6e8:480:60:787f:3bfd:4b90:9728]) by mx.google.com with ESMTPSA id z6sm81833493bkn.8.2013.12.04.06.27.34 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 06:27:35 -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: <5BCBA1FC2B7F0B4C9D935572D90006681519D739@DEMUMBX014.nsn-intra.net>
Date: Wed, 4 Dec 2013 16:27:34 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <E2BA2D43-B66A-4713-9B69-73A1E0FE1C30@gmail.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519BD77@DEMUMBX014.nsn-intra.net> <B2C75305-AC2B-40A3-AC3B-EA22AF3EF02F@nostrum.com> <C903D62B-DD1E-4FB3-99CC-F39F8BC8AD12@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519D739@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
X-Mailer: Apple Mail (2.1510)
Cc: Ben Campbell <ben@nostrum.com>, "dime@ietf.org" <dime@ietf.org>
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: Wed, 04 Dec 2013 14:27:45 -0000

- Jouni


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

> Jouni,
> 
> local configuration is exactly wht REQ6 aims to avoid.


I still do not agree on the MUST in your proposal, since the
REQ6 is SHOULD.

> 
> With regard to figure 4 in clause 5.1: why would the agent base its decision (to take over the role of the reacting node on behalf of the non supporting client) on local configuration data rather than on absence of the Feature-Vector AVP?

Because a network administrator may have a reason
beyond our current visibility to prohibit and agent
of doing so. For example the administrator might 
want to prohibit DOIC for some realms talking to
its servers.

- Jouni

> 
> Ulrich
> 
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
> Sent: Wednesday, December 04, 2013 11:03 AM
> To: Ben Campbell
> Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> Subject: Re: [Dime] endpoint determination
> 
> 
> On Dec 3, 2013, at 11:45 PM, Ben Campbell <ben@nostrum.com>; wrote:
> 
>> 
>> On Nov 28, 2013, at 6:21 AM, 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.
> 
> This should already be possible according to the current
> spec..
> 
>> I agree with the concepts in 1 and 2, but not as written (assuming you intend the use of must to be normative.) I think this is better written in terms of a definition of what reporting node and reacting node means, then mention that a supporting client is normally a reacting node, a supporting server is normally a reporting node, and an agent can be both.
>> 
>>> 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 
> 
> I do not agree the MUST here to be written into the spec.
> The agent is free to do the above procedure but it is an
> implementation & local config issue. 
> 
> - JOuni
> 
> 
>>> 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.
>> 
>> I read that to mean you expect an agent to "take over" as the reacting node even if the administrator has completely turned off OC? If so, I don't agree, at least not as a normative requirement. Implementors can choose to create such a mode if they want to, but we don't need to require it.
>> 
>> 
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>