[DMM] draft-ietf-dmm-fpc-cpdp-00 - update plans
Folks, draft-ietf-dmm-fpc-cpdp-00 is out since May. So far we did not receive any serious issue to address, which is good. Driving the draft towards a more mature state, I see the following main items to address: (1)Completion of properties and attributes (2)Adoption of a standard conform modelling In terms of (1), the importance to include QoS attributes has been raised from different sides. I'll make a proposal how to cover this in an update on the DMM ML using a separate eMail. Other attributes we may need to cover are about monitoring/reporting. In terms of (2) we heard different opinions about keeping this document at the level of information models or be more specific by adopting data modeling. So far the document is pretty hybrid ;-), core part is more about clear definition and description of messages and information to apply between Client and Agent. In the appendix the draft includes a (so far experimental) YANG model. Please state your opinion here to see what the WG expects from the document. If we adopt information modeling, this seems straightforward from a version which is complete in terms of messages/attributes. If we adopt data modeling, we may need to spend more cycles in agreeing formats, alignment, etc. Hope we can discuss on the ML. I'd also like to schedule a WebExt before the draft deadline. Will send a doodle around for that. marco ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
[DMM] How to cover QoS in draft-ietf-dmm-fpc-cpdp-00
Folks, as announced in my previous eMail, please find below a proposal how to address QoS in draft-ietf-dmm-fpc-cpdp-00. The draft adopts a model to abstract forwarding and policy configuration for DMM using logical ports which bind properties. This can be applied at Agents to any Data-Plane Node (DPN) configuration, routers, network controllers, switches. Adding QoS properties per port should be in-line with RFC7222 in case of GBR and MBR. More needs to be considered for aggregates, such as per-MN-AMBR, per-Session-AMBR. Here, the Control-Plane logic may accomplish configuration of the Data-Plane for an MN or Session using a single port or multiple ports. This can be tackled by permitting a Client to bind an AMBR attribute/value to a single port or to a group of ports. Whether the aggregate applies per-MN or per Session, should be kept in the application logic and be kept transparent to the Data-Plane. Information coming with an AMBR attribute needs to comprise a list of port identifies (PRT_ID) to which the aggregate applies, like: QOS_AMBR_CONF: Aggregate Bitrate //gives the maximum aggregate value List of Port-IDs //defines the group of ports where metering applies Please let me know if anything is missing. marco ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
