[Dime] Question regarding RFC 6733 on transport end disconnections

[Miguel Rodriguez Caudevilla <[e-mail]>]

Hello,

We are working in a product which uses an implementation of a diameter stack based on RFC 6733.
We recently had a discussions with the developers of the stack and after some thoughts and post analysis of the discussion, we personally think this could be due to an open interpretation of the RFC regarding DPR messages and how a stack implementation should deal with transport end disconnections. Let me try to explain the reason of the discussion.

We have a cluster wide distributed stack. The diameter instances in the cluster can be administratively be locked, which in consequence ends a transport end connection with a peer.

From https://tools.ietf.org/html/rfc6733#section-5.4 we interpret that the DPR/DPA flow before transport end disconnection is as follows (Simplified flow):

When a diameter instance disconnects one of its transport connections it must be notified to the peer with a DPR.
A DPA will be sent by the peer and the diameter instance initiates the transport disconnect.
The peer will receive the transport closure request and close its transport end.

What we argue is that what the peer does after this flow depends completely in the Disconnection-Reason AVP received in the DPR.

In our case, when the lock is performed we expected that the diameter stack would send a DPR with Disconnect-Cause REBOOTING, to inform the peer that the transport end connection is going to be closed and that the peer can immediately retry to connect as there are other diameter instances available to provide service in the same cluster.

The stack implementers have a different argument. The administrative lock of a single diameter instance, they consider that it is performed in a way that all the services on cluster level are available. So, it would be quite strange to indicate the peer disconnect-case REBOOTING for the loss of a single node considering we can still provide diameter service through all the other nodes in the cluster. So, the loss of a node (and connections handled by it) is a transient fault that is easily handled if the peer reconnects. They consider that this way the peer reconnects as quickly as possible in such cases. That the stack can achieve this according to the standard as well if it does not send any DPR with connection loss reasons.

They point to https://tools.ietf.org/html/rfc6733#section-2.1

A given Diameter instance of the peer state machine MUST NOT use more than one transport connection to communicate with a given peer, unless multiple instances exist on the peer, in which, case a separate connection per process is allowed.

And consider that a diameter disconnect cause (eg: REBOOTING or whatever else) sent by a diameter node to a peer actually reflects the overall state of the sending node. Since we have a cluster wide distributed implementation it would be not correct to send a disconnect case REBOOTING as that indicates the whole node is going to be rebooted. We just perform some node level operations while still providing full service to diameter peers.

We would like to have your point of view regarding this discussion.
Is this intentionally left open for the stack implementation?
Did we interpret something wrong?

Thanks in advance.

Best Regards,
Miguel Rodriguez Caudevilla