Early Review of draft-ietf-tsvwg-diffserv-intercon-09
review-ietf-tsvwg-diffserv-intercon-09-rtgdir-early-berger-2016-09-13-00

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and
sometimes on special request. The purpose of the review is to provide
assistance to the Routing ADs. For more information about the Routing
Directorate, please see
​

http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir



Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF
Last Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-tsvwg-diffserv-intercon-09
Reviewer: Lou Berger
Review Date: Sept 10
Intended Status: Informational

Summary:

    I have some minor concerns about this document that I think should
be resolved before publication.

Comments:

This document is being published as Informational as such my review and
comments focus more on the clarity of the document than its specific
recommendations.  While the document has no major issues, I think the
currently has a number of confusing, if not contradictory, statements
that should be clarified prior to publications.  There are also a number
of other issues, ranging from minor  to nit - level, that should also be
addressed.


Major Issues:

	No major issues found.

Minor Issues:

- The first issue is target use / applicability

The document title implies that the document scope may apply to any
provider interconnection as does 1st sentence of the 3rd paragraph 3 of
section 1; IP tunnels are also mentioned in Section 4.3. Yet the
Abstract and Section 1.2 state applicability is to MPLS-based providers.
 Section 4 then further narrows applicability 4 classes of traffic.

I think the applicability of this document to both (a) intra-provider
technologies and (b) supported traffic classes need to be clarified and
consistent across the document's Title, Abstract, Intro/Applicability
and other sections.

- Use of 'QoS'

I find QoS undefined in the document and is really being used
synonymously with 'traffic class', 'traffic treatment', 'DSCP', 'Class
of Service' and even DiffServ itself in the document.  I think the
intent and clarity of the document would be improved by removing or
replacing all instances of QoS.  This would obviate needing to define
what QoS means in the context of the specific (and limited) usage of
DiffServ, as well as avoid naming consistency with other documents.

- Intent of section 2

I found the purpose of Section 2 entirely unclear.  This may have been
due to some of the confusing text it contains (e.g.,  the 3rd sentence
of the Section - what is non-tunneled IP traffic in an MPLS network, and
why would an MPLS provider be tunneling traffic in IP tunnels?)

If it's merely to introduce MPLS Short Pipe's and PHP, then this is
accomplished in section 1 -- and by RFC3270 itself.  If this is the sole
purpose, than perhaps it would be easiest/best to just delete the
section or combine it with Appendix A.  If there is another purpose that
is core to the document, I think the text needs to be revised to make
that purpose clear,


Nits:

- The document is inconsistent in how it references RFCs.  At times, it
expands the RFC as text (e.g., "RFC 2475") other times it uses reference
notation (e.g., [RFC5127]) other times it uses both (e.g, RFC 5127
[RFC5127]).  Some consistency on use / intent would benefit the document.