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

[Norm Strahle <[e-mail]>]

Hey folks,  sorry, late response to Fred's comments questions below regarding traffic class for IPv6:

Here is our thinking on the subject. As you state, the IPv6 header has a “traffic-class” field, which consists of the DSCP portion and the ECN portion.  This draft discusses both packet classification and traffic conditioning.  When classifying on a packet, a router can classify on several packet elements, including DSCP. However, a router should not classify on ECN, as that is the role of the endpoints in the network. A router should mark ECN when detecting queue congestion. Thus, for configuration of classification on packets, the draft refers to DSCP rather than Traffic-class. The configuration for ECN marking based on queue congestion is vendor specific and is being left to vendor specific implementations.

 > On Dec 1, 2018, at 8:38 AM, Greg Mirsky <[e-mail]>; 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.