Re: [Dime] Issue#35 conclusion

Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> Thu, 06 March 2014 08:00 UTC

Return-Path: <maria.cruz.bartolome@ericsson.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 CD2791A0121 for <dime@ietfa.amsl.com>; Thu, 6 Mar 2014 00:00:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.239
X-Spam-Level:
X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 TIznOJwMHUwp for <dime@ietfa.amsl.com>; Wed, 5 Mar 2014 23:59:58 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id B571F1A0130 for <dime@ietf.org>; Wed, 5 Mar 2014 23:59:57 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-a6-53182af83762
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id F4.85.04853.8FA28135; Thu, 6 Mar 2014 08:59:53 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0387.000; Thu, 6 Mar 2014 08:59:52 +0100
From: Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com>
To: "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac85Egw/MXVwSViOSJ+HwVeoYWkoDw==
Date: Thu, 06 Mar 2014 07:59:51 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920978A014@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.149]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B920978A014ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvje5PLYlggzczuC3m9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxurLe1kLNq5jrHjzv525gfHMLMYuRk4OCQETic0HP7JA2GIS F+6tZ+ti5OIQEjjBKNGw/wmUs4hRovlMJxtIFZuAncSl0y+Yuhg5OEQElCVO/3IACQsLqEvc +X6BFcQWEdCQaHzziR3C1pN49KcbzGYRUJHY8mYmWA2vgK/Eve45YHFGoMXfT61hArGZBcQl bj2ZzwRxkIDEkj3nmSFsUYmXj/+xQthKEmsPb2eBqM+XeHb3KhPETEGJkzOfsExgFJqFZNQs JGWzkJRBxHUkFuz+xAZha0ssW/iaGcY+c+AxE7L4Akb2VYySxanFxbnpRgZ6uem5JXqpRZnJ xcX5eXrFqZsYgfFxcMtvox2MJ/fYH2KU5mBREue9zloTJCSQnliSmp2aWpBaFF9UmpNafIiR iYNTqoExVF93i3/E2lrBzKdhpkpLTlrVSHA9Y5si1nJrvkrUAvOODN8nDglPc7t6VvmwpCjN XuiitevT8uKb3+6W+Z6XXbV/z4sNVe+DG1dV/z/4pnXK3DN7jE4bBc9br860959FYvnHXZ7N /lGWjYcVha6f/xOr9/G/s81L3/c33wavYpxya5FbVth1JZbijERDLeai4kQAWD38TF0CAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/iJRIeR6t_zGj68gtjHg1d7eRzHs
Subject: Re: [Dime] Issue#35 conclusion
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, 06 Mar 2014 08:00:01 -0000


Dear all,

This mail thread started proposing new OLR reports to request reduction for one specific client.
However, the discussion clarified that as it is the draft today, Host-report is sent from a reporting node towards the client from where it receives the request. Then, reduction is requested per client in all cases already.
There is one special case here, when the agent is acting on behalf of the client (i.e. for a non-supporting client or for an agent SFE with topology hiding). In this case, the reporting node sends host-report to agent. Here we have two options:


a)     We expect the agent to apply the host-report received in an answer to specifically the client that sent the corresponding request

This requires some extra complexity at agent side.

But here we have one more option: allow the reporting node to choose whether it prefers to apply this host-report to "all-client" vs "one-client". That increases again the complexity (at reporting node, protocol-wise, and at agent).



b)     We expect the agent to apply this host-report to any client that is sending a request towards this agent

In my opinion, this is the best approach, it reduces complexity and increases robustness.

Therefore, I will be in favor of option b), which does not require any changes to the actual draft.

Let me know your opinions.
Best regards
/MCruz