Subject: [tsvwg] draft-ietf-l3sm-l3vpn-service-model-16 - YANG Data Model for L3VPN service delivery

From: Brian E Carpenter <[email-masked]>
Date: Fri, 7 Oct 2016 08:58:34 +1300

Hi,

As a Gen-ART reviewer, I drew the short straw for:

https://tools.ietf.org/html/draft-ietf-l3sm-l3vpn-service-model-16

which is in IETF Last Call ending 2016-10-11:
https://mailarchive.ietf.org/arch/msg/ietf-announce/L5feYhXtLXWe-HYIZqJrBXRbNDo

I'd like to suggest that people here take a look at sections 5.12.2
(QoS) and 5.13.2 (Transport constraints) and respond to the Last
Call (not to me!) if they have any concerns.

Regards
   Brian Carpenter

---

From: <[email-masked]>
Date: Fri, 7 Oct 2016 10:55:11 +0000

Hi Brian,

I've had a look at the QoS section.

Page 72 top is related to classification:

   The order of rules is really important.  The management system
   responsible for translating those rules in network element
   configuration MUST keep the same processing order in element
   configuration.  The order of rule is defined by the "id" leaf.  The
   lowest "id" MUST be processed first.

This makes sense. I noted that there seems to be a "default" classification in the draft example, which is rule <ID>4</4> (the final rule). I'm not a YANG expert. "Default" here is indicated by 
- "no classification rule" prior to assigning  a "target class". 
- last rule by processing order
If that's how YANG handles a default rule, I got no comment. Otherwise my question is, whether "default" or "terminal rule" should be indicated explicitely.

Page 72
      guaranteed-bw-percent : used to define a guaranteed amount of
      bandwidth for the class of service.  It is expressed as a
      percentage.  The guaranteed-bw-percent uses available bandwidth at
      the priority-level of the class.

This links priority levels to rate queues. I doubt that this is a general configuration. I suggest to differ between classes based on rate queues and classes based on priority queues by a separate indicator. Only the queues based on priority queuing need to be ranked.

Maybe, I'm worried here also because it is somewhat hard to differ what is customized and what's SP standard configuration. Neither queue-depth nor burst sizes appear - these seem to be based on an SP standard configuration. The question to me is, whether classes as such aren't following an SP standard and by a given class name it is set already, whether that class is produced by priority queuing or by a rate queue. If the classes are customer defined, additional parameters like queue-depth and policer burst sizes need to be defined (maybe WRED too).

It further may be useful to indicate a layer to which a rate refers, especially if QoS is fully customized.

This text doesn't mention metering / accounting of QoS traffic. I think it should, if classes are completely customized.

Minors

Page 72:
a device scheduling policy may be implemented both 
at PE and CE side on the WAN link.
                         ^^^^^^^^
"WAN link" is standard terminology for the interface of the PE to CE? "WAN access" was used on page 69. Using the same terminology may be helpful.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: tsvwg [mailto:[email-masked]] Im Auftrag von Brian E Carpenter
Gesendet: Donnerstag, 6. Oktober 2016 21:59
An: [email-masked]
Betreff: [tsvwg] draft-ietf-l3sm-l3vpn-service-model-16 - YANG Data Model for L3VPN service delivery

Hi,

I'd like to suggest that people here take a look at sections 5.12.2
(QoS) and 5.13.2 (Transport constraints) and respond to the Last Call (not to me!) if they have any concerns.

Regards
   Brian Carpenter