Subject: [Dime] Comments for draft-ietf-dime-diameter-qos-06

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 18 Jul 2008 11:19:22 -0400

1- Use of the same Application-Id for push/pull models
It sounds reasonable to me to think nodes which support only a single
mode. How can we guarantee that messages land to the right server
considering that the same Application-Id is used for both of them?

2- 3. Framework
   "After receiving the
   authorization request from the AppS or the NE, the AE decides the
   appropriate mode (i.e.  Push or Pull).  The usage Push or Pull mode
   can be determined by the authorizing entity either statically or
   dynamically."
I think I am missing something here. Don't we have always push mode if
the authorization request is received from AppS? Or are we talking about
a hybrid model where first AppS contacts the Authorizing Entity,
receives a token, hands it over to media layer, and this token is used
in turn by NE for pull mode?

3- 3. Framework
   "For Push mode, the authorizing entity needs to identify the
   appropriate NE(s) to which QoS authorization information needs to be
   pushed.  It might determine this based on information received from
   the AppS, such as the IP addresses of media flows."
It could be a good idea to give a bit more information about this:
- This is hard to do as Authorizing Entity would need to have
information about routing decisions of NEs for a particular flow
-  QoS in the core network is usually not scarce
-  QoS on the access side is scarce
-  It is not difficult for the Authorizing Entity to determine NEs
facing the access side as usually this information is stored somewhere
when the endpoint attaches to the network and does not change per IP
flow.

4- 3.4 QoS Application Requirements

      "Identity-based Routing
      The QoS AAA protocol MUST route AAA requests to the Authorizing
      Entity, based on the provided identity of the QoS requesting
      entity or the identity of the AE encoded in the provided
      authorization token."

I think it is responsibility of the QoS application -not QoS AAA
protocol- to perform routing decision based on identity. The application
decided for the host/realm and the protocol routes the message based on
that.

I think it could be better to have a global change in this section:
QoS AAA protocol ==> QoS AAA application

5- 3.4 QoS Application Requirements
      "Sending Accounting Records
      The NE SHOULD be able to send accounting records for a particular
      QoS reservation state to an accounting entity."
Is this a QoS AAA application requirement? It is stated as a requirement
on NE.

6- 4.2 Session Establishment
   "When a QoS-Authz-Request
   (QAR, see Section 5.1) message with a new session ID is received, the
   AE operates in the Pull mode; when other triggers are received, the
   AE operates in the Push mode."
Would this shut down the door for certain failure recovery scenarios?
For example AE goes down and a backup AE takes over. IMO it is a nice
feature if the backup can continue existing sessions without a need to
synchronizing state with the failed active AE. This can be achieved by
carrying enough information about session state in the message itself
(AFAIR, DCCA can do this nicely). The approach I quoted makes this
impossible. For certain scenarios backup AE would determine the required
mode wrong. I suggest the decision for push/pull is not based on message
name but on the message content.

7- There were some proposals about a mode, where NE is notified from AE
to reserve resources all the way till the end point. Is this considered
out of scope?

Thanks,
Tolga

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime