Subject: Re: WG adoption poll for draft-asechoud-rtgwg-qos-model-07

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 1 Dec 2018 11:55:00 +0000

I support WG adoption of this YANG model.
Acee

From: rtgwg <[email-masked]> on behalf of Jeff Tantsura <[email-masked]>
Date: Friday, November 30, 2018 at 9:31 PM
To: Routing WG <[email-masked]>
Cc: Routing WG <[email-masked]>
Subject: WG adoption poll for draft-asechoud-rtgwg-qos-model-07

Dear RTGWG,

The authors have requested RTGWG to adopt draft-asechoud-rtgwg-qos-model as the working group document.
The draft has received support during IETF101 meeting, authors have addressed all the comments received.

Please indicate support or no-support by December 15, 2018.

If you are listed as a document author or contributor please respond to this
email stating of whether or not you are aware of any relevant IPR.
The response needs to be sent to the RTGWG mailing list. The document will not
advance to the next stage until a response has been received from each
author and each individual that has contributed to the document..

Cheers,
Jeff & Chris

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 1 Dec 2018 08:38:03 -0800

Dear Authors,
thank you for taking on this work. I have a question rather philosophical
than technical. The title of the draft suggests that the models are generic
though they are based on DSCP field of the IP header. Have you considered
extending models to include the Traffic Class field of MPLS Label element?
And if not, then clarify that the models are for networks with IP data
plane?

Regards,
Greg

On Fri, Nov 30, 2018 at 6:31 PM Jeff Tantsura <[email-masked]>
wrote:

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

---

From: Fred Baker <[email-masked]>
Date: Sat, 1 Dec 2018 12:33:23 -0800

> On Dec 1, 2018, at 8:38 AM, Greg Mirsky <[email-masked]> wrote:
> 
> Dear Authors,
> thank you for taking on this work. I have a question rather philosophical than technical. The title of the draft suggests that the models are generic though they are based on DSCP field of the IP header. Have you considered extending models to include the Traffic Class field of MPLS Label element? And if not, then clarify that the models are for networks with IP data plane?
> 
> Regards,
> Greg

I would support Greg's comment above. I would add that the DSCP discussed in the draft is called the "Traffic Class" in IPv6 (cf RFC 8200), and it would be nice to add an explanatory sentence somewhere observing on the fact. On the first usage of "DSCP", in addition to the link to RFC 2474, perhaps it should be expanded to "DSCP, Traffic Class [RFC8200], or Traffic Class [correct MPLS RFC]". Or something equivalent.

On a technical note, it seems strange to refer to a Cisco proprietary queue management structure (MDRR, cf https://www.cisco.com/c/en/us/support/docs/routers/12000-series-routers/18841-mdrr-wred-18841.html) and a research paper intended for EPON networks (PWFQ, http://adsabs.harvard.edu/abs/2005SPIE.6022..220X), but not the diffserv architecture, or at least without explaining that the "policing policy" etc derive from diffserv.

---

From: "Aseem Choudhary (asechoud)" <[email-masked]>
Date: Mon, 3 Dec 2018 04:42:07 +0000

Hi Greg,

Thanks for your question.

This draft defines the QoS base modules of Policy, Classiier, Action, Target. QoS base module has been augmented with Diffserv module.
This is described in Section 1.
For MPLS, similar modules will be augmented as part of separate draft. This has not been specifically mentioned but can be added.

Regards,
Aseem

From: rtgwg <[email-masked]> on behalf of Greg Mirsky <[email-masked]>
Date: Saturday, December 1, 2018 at 8:38 AM
To: Jeff Tantsura <[email-masked]>
Cc: rtgwg-chairs <[email-masked]>, RTGWG <[email-masked]>
Subject: Re: WG adoption poll for draft-asechoud-rtgwg-qos-model-07

Dear Authors,

Regards,
Greg

On Fri, Nov 30, 2018 at 6:31 PM Jeff Tantsura <[email-masked]<mailto:[email-masked]>> wrote:
Dear RTGWG,

Cheers,
Jeff & Chris
_______________________________________________
rtgwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtgwg

---

From: "Aseem Choudhary (asechoud)" <[email-masked]>
Date: Mon, 3 Dec 2018 04:50:43 +0000

Hi Fred,

Thanks for your comments. 

Please see replies inline.

Regards,
Aseem.

On 12/1/18, 12:33 PM, "rtgwg on behalf of Fred Baker" <[email-masked] on behalf of [email-masked]> wrote:

    
    
[AC] Agreed, will add it.

[AC] Diffserv behavior is defined in section 4.  Based on it, policing is defined inline or as template. The priority defined for queuing is not mandatory and hence become priority entry based on whether defined or not. Similarly for min-rate, max-rate. There is no specific reference to MDRR. The queuing actions are defined as per classifier entry or as separate queuing policy.

---

From: Fred Baker <[email-masked]>
Date: Mon, 3 Dec 2018 10:39:53 -0800

> On Dec 2, 2018, at 8:50 PM, Aseem Choudhary (asechoud) <[email-masked]> wrote:
> 

If there is no reference to MDRR, I find the following confusing:

     identity mdrr-queuing-policy {
       base compc-qos-policy;
     }

   ...
         must "((../sub-type != 'mdrr-queuing-policy') and " +
              " (../sub-type != 'pwfq-queuing-policy')) or " +
              "(((../sub-type = 'mdrr-queuing-policy') or " +
              "  (../sub-type = 'pwfq-queueing-policy')) and " +
   ...

       container traffic-queue {
         when "(../sub-type = 'mdrr-queuing-policy') or " +
              "(../sub-type = 'pwfq-queuing-policy')" {
           description
             "Queuing policy properties";
         }
(Twice)
   ...
       case mdrr-queuing-policy {
         when "../../../sub-type = 'mdrr-queuing-policy'" {
           description
             "MDRR queue handling properties for the traffic " +
             "classified into current queue";
         }
         leaf mdrr-queue-weight {
           type uint8 {
             range "20..100";
           }
           units percentage;
         }
       }

--------------------------------------------------------------------------------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu

---

From: "Aseem Choudhary (asechoud)" <[email-masked]>
Date: Mon, 3 Dec 2018 18:44:35 +0000

Ahh.. got it. 

This is company C example (Section: Example of Company C Diffserv Model).
 It is just an example to indicate how to append the model for each vendor requirements.

Best Regards,
Aseem

On 12/3/18, 10:40 AM, "Fred Baker" <[email-masked]> wrote:

    

       ...

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 3 Dec 2018 17:33:14 -0800

Hi Aseem,
much appreciate your expedient response. I still wonder if your intention
to build a generic model of QoS, then why it uses specific only to IPv4
DSCP value? For example, in the last paragraph of the Introduction section,
you've stated:
   The traffic streams are differentiated
   based on DiffServ Code Points (DSCP) carried in the IP header of each
   packet.
That is true but only for the network with IP data plane, IPv4 to be more
precise, as pointed Fred. Should the generic QoS model be less specific
about the data plane technology
And I got a more technical question to authors:

Why use inet:ipv4-address and inet:ipv6-address explicitly rather than
implicitly by using inet:ip-address?

Regards,
Greg

On Sun, Dec 2, 2018 at 8:42 PM Aseem Choudhary (asechoud) <
[email-masked]> wrote:

> This draft defines the QoS base modules of Policy, Classiier, Action,
> Target. QoS base module has been augmented with Diffserv module.
>
> For MPLS, similar modules will be augmented as part of separate draft.
> This has not been specifically mentioned but can be added.
>
>
>
> Regards,
>
> Aseem
>
>
>
> *From: *rtgwg <[email-masked]> on behalf of Greg Mirsky <
> [email-masked]>
> *Date: *Saturday, December 1, 2018 at 8:38 AM
> *To: *Jeff Tantsura <[email-masked]>
> *Cc: *rtgwg-chairs <[email-masked]>, RTGWG <[email-masked]>
> *Subject: *Re: WG adoption poll for draft-asechoud-rtgwg-qos-model-07
>
>
>
> Dear Authors,
>

---

From: "Aseem Choudhary (asechoud)" <[email-masked]>
Date: Tue, 4 Dec 2018 08:03:10 +0000

Hi Greg,

Please find replies inline.

Regards,
Aseem

From: Greg Mirsky <[email-masked]>
Date: Monday, December 3, 2018 at 5:33 PM
To: "Aseem Choudhary (asechoud)" <[email-masked]>
Cc: Jeff Tantsura <[email-masked]>, rtgwg-chairs <[email-masked]>, RTGWG <[email-masked]>
Subject: Re: WG adoption poll for draft-asechoud-rtgwg-qos-model-07

Hi Aseem,
much appreciate your expedient response. I still wonder if your intention to build a generic model of QoS, then why it uses specific only to IPv4 DSCP value? For example, in the last paragraph of the Introduction section, you've stated:
   The traffic streams are differentiated
   based on DiffServ Code Points (DSCP) carried in the IP header of each
   packet.
That is true but only for the network with IP data plane, IPv4 to be more precise, as pointed Fred. Should the generic QoS model be less specific about the data plane technology

[AC] I think the statement is in the context of extension to previous statement   “The DiffServ model is based on DiffServ architecture, and various references have been made to

   available standard architecture documents.” .  I think it is fine to be part of Section 1 rather than moving to Section 4 for Diffserv model design.

And I got a more technical question to authors:
Why use inet:ipv4-address and inet:ipv6-address explicitly rather than implicitly by using inet:ip-address?

[AC] This was done to define policy-types ipv4 and ipv6 and inet:ip-address was accordingly split into inet:ipv4-address and inet:ipv6-address.

Regards,
Greg

On Sun, Dec 2, 2018 at 8:42 PM Aseem Choudhary (asechoud) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Regards,
Aseem

From: rtgwg <[email-masked]<mailto:[email-masked]>> on behalf of Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Saturday, December 1, 2018 at 8:38 AM
To: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>
Cc: rtgwg-chairs <[email-masked]<mailto:[email-masked]>>, RTGWG <[email-masked]<mailto:[email-masked]>>
Subject: Re: WG adoption poll for draft-asechoud-rtgwg-qos-model-07

Dear Authors,

Regards,
Greg

Cheers,
Jeff & Chris

---

From: tom petch <[email-masked]>
Date: Tue, 4 Dec 2018 11:09:18 +0000

Viewed as a YANG module, there are a number of defects in this I-D.  I
think that the flavour is well illustrated by:

- s.5 This document defines five YANG modules
The Table of Contents lists seven

Copyright statements are all 2014.

revision date of  s.6.1  is 2016-03-03

yang-version is a mixture of 1 and 1.1

IANA gets no mention, not even a TBD.

No mention of NMDA

The modules are devoid of any YANG reference statements, either for
import or for description.

No reference for Tree Diagrams.

No current reference for YANG itself or Interface Management

The (unanswered) technical question is why have so many modules; I am a
fan of separate modules for YANG types and YANG identities, since I see
them as having a different evolution, but that is not done here; rather,
the functionality is broken up, leading to more YANG prefixes, modules
that are more complex. Why?

Tom Petch

----- Original Message -----
From: "Jeff Tantsura" <[email-masked]>
To: "RTGWG" <[email-masked]>
Cc: "Routing WG" <[email-masked]>
Sent: Saturday, December 01, 2018 2:30 AM
Subject: WG adoption poll for draft-asechoud-rtgwg-qos-model-07

> Dear RTGWG,
>
> The authors have requested RTGWG to adopt
draft-asechoud-rtgwg-qos-model as the working group document.
> author and each individual that has contributed to the document..

------------------------------------------------------------------------
--------

---

From: "Aseem Choudhary (asechoud)" <[email-masked]>
Date: Tue, 4 Dec 2018 22:17:09 +0000

Hi Tom,

Thanks for the comments.

Please see some comments inline.

Regards,
Aseem

On 12/4/18, 3:09 AM, "rtgwg on behalf of tom petch" <[email-masked] on behalf of [email-masked]> wrote:

    

[AC] I thought it is for last modified date.

[AC] I am not sure it needs to be all 1 or 1.1

    No mention of NMDA

    

[AC] I see below three YANG references. Am I missing something?

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <https://www.rfc-editor.org/info/rfc6020>.

   [RFC6991]  Schoenwaelder, J., Ed., "Common YANG Data Types",
              RFC 6991, DOI 10.17487/RFC6991, July 2013,
              <https://www.rfc-editor.org/info/rfc6991>.

   [RFC7223]  Bjorklund, M., "A YANG Data Model for Interface
              Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
              <https://www.rfc-editor.org/info/rfc7223>.

[AC] These modules are basic building blocks for a QOS model. The functionality is logically broken into different modules.
         YANG types and identities defined are for the specific module. Not sure what you find complex here than it needs to be.

    Tom Petch

---

From: tom petch <[email-masked]>
Date: Wed, 5 Dec 2018 12:31:51 +0000

Aseem

On the references,  where you have an import, e.g.
     import ietf-qos-classifier {       prefix classifier;     }
you should say where this is to be found
e.g.
  import ietf-network {    prefix "nw";
    reference  "RFC 8345: A YANG Data Model for Network Topologies";  }
or
     import ietf-qos-classifier {  prefix classifier;
         reference "RFC XXXX: YANG Model for QoS";      }
-- Note to RFC Editor please replace XXXX with the number assigned to
this I-D

On YANG description, I expect many, if not most, clauses to have a
reference - see, for example, RFC8348 for a well-populated module.

On YANG version, the current version is 1.1 and has been for over two
years, so if you want the previous version for some reason, like using
TLS1.0 instead of TLS1.3, then that needs justifying.

On multiple modules, the more modules the more prefixes and the longer
the references to an object in another module so you have e.g.
        augment "/policy:policies" +
                "/policy:policy-entry" +
                "/policy:classifier-entry" +
                "/policy:classifier-action-entry-cfg" +
                "/policy:action-cfg-params" +
                "/diffserv:meter-inline" +
                "/diffserv:meter-type" +
                "/diffserv:one-rate-tri-color-meter-type" +
                "/diffserv:one-rate-tri-color-meter" {
instead of, perhaps,
  augment
"/policies/policy-entry/classifier-entry/classifier-action-entry-cfg" +
                "/action-cfg-params/meter-inline/meter-type" +

"/one-rate-tri-color-meter-type/one-rate-tri-color-meter" {
were they all to be in the same module.  This also applies to when
statements.

There is, unfortunately, in YANG no way of saying assume "policy:" until
I say "diffserv:".  It is when third parties augment with custom
features that it gets messier.  So, my personal view, is that separate
modules needs justification, such as the expectation that they will
evolve differently - but then that suggests that they should be in
separate RFC!  I grant that classifying, metering, marking, etc are
distinct pieces of technology but I am less convinced of the case for
separate YANG modules.  Look, for example, at
draft-ietf-isis-yang-isis-cfg
to see a single module encompassing several aspects of one protocol.

Tom Petch

----- Original Message -----
From: "Aseem Choudhary (asechoud)" <[email-masked]>
To: "tom petch" <[email-masked]>; "Jeff Tantsura"
<[email-masked]>; "RTGWG" <[email-masked]>
Cc: "Routing WG" <[email-masked]>
Sent: Tuesday, December 04, 2018 10:17 PM

> On 12/4/18, 3:09 AM, "rtgwg on behalf of tom petch"
<[email-masked] on behalf of [email-masked]> wrote:
> [AC] These modules are basic building blocks for a QOS model. The
functionality is logically broken into different modules.
>          YANG types and identities defined are for the specific
module. Not sure what you find complex here than it needs to be.
>     > The draft has received support during IETF101 meeting, authors
have
>     addressed all the comments received.
>     >
>     > If you are listed as a document author or contributor please
respond
>     to this
>     > The response needs to be sent to the RTGWG mailing list. The
document
>     will not

---

From: "Aseem Choudhary (asechoud)" <[email-masked]>
Date: Thu, 6 Dec 2018 08:35:57 +0000

Thanks Tom, I will discuss these points with my co-authors.
Let us know any other feedback you may have.

Regards,
Aseem

On 12/5/18, 4:32 AM, "tom petch" <[email-masked]> wrote:

    Aseem

    

    
    
    Tom Petch

    ----- Original Message -----
    From: "Aseem Choudhary (asechoud)" <[email-masked]>
    To: "tom petch" <[email-masked]>; "Jeff Tantsura"
    <[email-masked]>; "RTGWG" <[email-masked]>
    Cc: "Routing WG" <[email-masked]>
    Sent: Tuesday, December 04, 2018 10:17 PM

    have
    respond
    document