Subject: [RTG-DIR] RtgDir review: draft-ietf-tsvwg-diffserv-intercon-09

From: Lou Berger <[email-masked]>
Date: Sat, 10 Sep 2016 14:59:55 -0400

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.

---

From: <[email-masked]>
Date: Tue, 20 Sep 2016 14:19:57 +0000

Hi Lou,

thanks for your review and feedback. My response took a few days (I tried to coordinate with David, but failed to reach him).

I will change the document in several parts trying to follow your guidance. I'd like to discuss your comment related to section 2.

The Introduction mentions Short-Pipe and says Diffserv-intercon is useful for it. I don't think the latter introduces MPLS Short Pipe to a reader if it isn't operational in his own network. One of the implications of MPLS Short Pipe for non tunneled IP is rewrite DSCP unknown to zero at the network Ingress. Non-tunneled is distinguished from tunneled IP (could be an IP-tunnel, could be IP traffic routed via an IP over MPLS VPN). Should we add an explanation of "non-tunneled IP"?

MPLS Short Pipe use according to RFC3270 and here for the non-tunneled IP traffic is as follows, I think (X, Y, Z indicate DiffServ Domains, IR and ER Ingress Router and Egress Router, PLSR Pen-ultimate LSR):

X - [IR] - Y - [PLSR] - Y Forwarding, X DSCP - [ER] - X
                      - Y Forwarding, Y DSCP - [ER] - Y

Capitol letter alone: Forwarding and MPLS TC/DSCP respectively of that domain.

Diffserv-Intercon is close to that. Let's add Diffserv-intercon's D DSCP and assume that each domain operates the Diffserv-intercon PHBs by an own domain flavour:

X Forwarding, D DSCP - [IR] - Y - [ER] - Y Forwarding, D DSCP
                            - Y - [ER] - Y 

Replace "D DSCP" by "X DSCP" -> a similarity with RFC3270 as originally designed is visible.

Taking each line of the example as an option for a realization, both cases are possible and interoperable in the Diffserv-intercon case.

I thought, a separate section is useful to indicate why there's a rewrite of the incoming DSCP for non-tunneled IP at the ingress. Deutsche Telekom doesn't support the first line showing Short Pipe as specified by RFC3270. The LERs do not handle traffic with DSCPs of downstream networks. Diffserv-intercon offers a kind of replacement here.

Regards, Ruediger

-----Message-----
From: Lou Berger [mailto:[email-masked]] 
mailed: Samstag, 10. September 2016 21:00
To: [email-masked]
Cc: [email-masked]; [email-masked]; tsvwg
Subject: RtgDir review: draft-ietf-tsvwg-diffserv-intercon-09

[snip]

Minor Issues:

[snip]

- 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,

[snip]

---

From: "Black, David" <[email-masked]>
Date: Wed, 21 Sep 2016 02:14:11 +0000

Lou,

[Commenting as a draft author, not WG chair]

Thanks for the review, and sorry for the delayed response  - EMC is now part
of Dell, and my life's been "interesting" as a result ...

Ruediger's commented on your Section 2 concern, so I'll pick up the other
two minor issues, and add some more commentary on Section 2 ...

> Abstract and Section 1.2 state applicability is to MPLS-based providers.

Applicability is to any provider interconnection, with suitability for
MPLS-based providers being a significant design goal/rationale, due to
the limited number of bits/values available for Diffserv in an MPLS label.

>  Section 4 then further narrows applicability 4 classes of traffic.

That definitely needs editing attention, as the 4 aggregated classes
of traffic are the core of the design - almost any network traffic can
be carried via an interconnection using the structure described in this
draft.  All of the traffic classes defined in RFC 4594 have been
covered in the specification of the aggregates.

> DiffServ, as well as avoid naming consistency with other documents.

Ok, we'll at least greatly reduce use  of "QoS" or eliminate it entirely.

> - Intent of section 2
> 
> I found the purpose of Section 2 entirely unclear.

[... snip ...]
 
> accomplished in section 1 -- and by RFC3270 itself.  

Nope, Section 2's purpose is to outline the constraints on the design
space that lead to what we did.  Diffserv tunneling is described in
RFC 2983, where the tunnel header is removed at the tunnel egress,
so two DSCP values are available to the tunnel egress node.   MPLS
short pipe's use of PHP (as described in RFC 3270) departs from RFC 2983
with the result that only one usable DSCP value is available to the tunnel
egress node.   Explaining that and the resulting design restrictions
is the primary purpose of Section 2, see the last paragraph in that
section - this is needed to make the draft accessible to those who
aren't MPLS experts.

Along the way, it was also necessary to dismiss RFC 2474's
recommendation to "forward traffic with unrecognized DSCPs
with Default (best effort) service without rewriting the DSCP"
as poor operational practice and focus on traffic that does not
use a provider-provisioned IP tunnel across the provider's
network.  These constraints plus MPLS short-pipe PHP
severely limit the design space.

Thanks, --David

> -----Original Message-----
> Sent: Saturday, September 10, 2016 3:00 PM
> To: [email-masked]

---

From: Lou Berger <[email-masked]>
Date: Mon, 26 Sep 2016 11:47:53 -0400

Hi Ruediger,

    Thanks for the response -- see below.

On 9/20/2016 10:19 AM, [email-masked] wrote:
> The Introduction mentions Short-Pipe and says Diffserv-intercon is useful for it. I don't think the latter introduces MPLS Short Pipe to a reader if it isn't operational in his own network. One of the implications of MPLS Short Pipe for non tunneled IP is rewrite DSCP unknown to zero at the network Ingress. Non-tunneled is distinguished from tunneled IP (could be an IP-tunnel, could be IP traffic routed via an IP over MPLS VPN). 

> Should we add an explanation of "non-tunneled IP"?
Perhaps this would help.

> I thought, a separate section is useful to indicate why there's a rewrite of the incoming DSCP for non-tunneled IP at the ingress. Deutsche Telekom doesn't support the first line showing Short Pipe…
Perhaps the intent will be more clear once you revise as you were
suggesting above.

Thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Mon, 26 Sep 2016 12:06:08 -0400

Hi David,

    Thanks for the response -- see below...

> the limited number of bits/values available for Diffserv in an MPLS label.

Okay - so it's any type of provider and motivated/constrained by
providers that use MPLS Short-Pipe tunnels.  Right?

If yes, the Abstract/intro/etc should be revised to be consistent with
this. 

> draft. 
"any" is a pretty broad statement.  I wouldn't argue with "almost any
DiffServ traffic".

>  All of the traffic classes defined in RFC 4594 have been

Elimination would be great.

> section 

> - this is needed to make the draft accessible to those who
> aren't MPLS experts.

Then perhaps add a statement to this effect, e.g., something along the
lines of "This section provides a summary of the implications of using
the MPLS short pipe's use of PHP (as described in RFC 3270) on RFC
2983."   Or what ever phrase you want to make it clear that this section
is simply background information and not trying to define anything new
to be considered.

> with Default (best effort) service without rewriting the DSCP"

humm, so you are trying to deprecate/change the RFC2119 language of a
standards track document in an informational document?  Seems like a bit
of odd way to accomplish an update.  Is this really the goal?

Thanks,
Lou

---

From: "Black, David" <[email-masked]>
Date: Mon, 26 Sep 2016 19:43:55 +0000

Hi Lou,

I think we're mostly aligned.  Two follow up comments are below, and
I concur with the rest of your remarks.

- [1] -
> providers that use MPLS Short-Pipe tunnels.  Right?

Yes, right.

> If yes, the Abstract/intro/etc should be revised to be consistent with

Will do.

- [2] -

Nope, the next words in my note after the above RFC 2474 quote were:

> > as poor operational practice

So, the goal is to characterize that RFC 2474 recommendation as not
relevant in practice to the network operator interconnect scenarios
discussed in this draft, as network operators don't deploy Diffserv
in that fashion.

Actually changing RFC 2474 is not a goal - that would entail a broader,
rather different standards-track draft (e.g., that encompasses data
center and enterprise network Diffserv usage, which are out of scope
for this informational draft), and at least right now, I'm not interested
in opening that can of worms ;-).

Ruediger and I will work together to revise the draft - your comments
are definitely appreciated.

Many Thanks, --David

> Sent: Monday, September 26, 2016 12:06 PM
> To: Black, David; [email-masked]
> Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-tsvwg-diffserv-intercon-09
> 
> Hi David,
>