Subject: [Dime] Diameter group signaling draft - summary of revision and added clarification

From: Marco Liebsch <[email-masked]>
Date: Mon, 20 Feb 2017 16:13:37 +0000

Please find a revised version of the Diameter group signaling draft on the IETF repository:

Abstract:

   In large network deployments, a single Diameter node can support over

   a million concurrent Diameter sessions.  Recent use cases have

   revealed the need for Diameter nodes to apply the same operation to a

   large group of Diameter sessions concurrently.  The Diameter base

   protocol commands operate on a single session so these use cases

   could result in many thousands of command exchanges to enforce the

   same operation on each session in the group.  In order to reduce

   signaling, it would be desirable to enable bulk operations on all (or

   part of) the sessions managed by a Diameter node using a single or a

   few command exchanges.  This document specifies the Diameter protocol

   extensions to achieve this signaling optimization.

The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-dime-group-signaling/

We addressed almost all comments made to the previous versions.
I could check with some of you how these comments have been addressed in the revision before posting the update.
One item is open about client action after receiving limited success during group operation. I'll send a separate eMail on this.

Please let us know if the comments have been well addressed.

Summary of main revisions/clarification:

Group Assignment:

*        Adopted RFC2119 rules for keywords in the core part of the specification about protocol operation (Sec 4).
Some description in the protocol overview part, e.g. permission considerations, also come with
upper case MUST.

*        In case the server cannot assign a new session to one or multiple session group(s) per the
client's request, the server can indicate success to the client in the result code but clears the
SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control-Vector.
This solution does not require the client to retry with a request without group assignment
(single-session fallback). Clarifying text has been added to page 9.

*        In case a client requests the server to assign a session to multiple session groups and the
server can assign the session to some but not all identified session groups, the session group
assignment is treated as failure (all or nothing principle, very pragmatic). Response MAY indicate
the groups for which assignment failed in the response. Clarifying text has been added to page 9.

*        To handle the case where the server decides to assign a session to one or multiple groups (client has not set
a value for the Session-Group-Ids in the included Session-Group-Info AVPs) but the client fails to add the session
to the session groups identified the in server's response, the client must terminate the session. In a subsequent
request the client will indicate to the server to not assign the session to any session group. Clarifying
text has been added to page 10.

*        A client which includes Session-Group-Info AVPs into the request at session initiation but cannot find
the Session-Group-Info AVP in the response processes the session as single session only. The client
SHOULD NOT retry to request group assignment for this session but MAY try to request group
assignment for other new session.

*        Clarifying text has been added to section 5 about the operation with Proxy Agents.

Best regards,
Marco