Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-diffserv-intercon-01.txt

From: [email-masked]
Date: Mon, 09 Mar 2015 08:50:50 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Area Working Group Working Group of the IETF.

        Title           : DiffServ interconnection classes and practice
        Authors         : Ruediger Geib
                          David L. Black
	Filename        : draft-ietf-tsvwg-diffserv-intercon-01.txt
	Pages           : 22
	Date            : 2015-03-09

Abstract:
   This document proposes a limited set of DiffServ PHBs and codepoints
   to be applied at (inter)connections of two separately administered
   and operated networks.  Many network providers operate MPLS using
   Treatment Aggregates for traffic marked with different DiffServ PHBs,
   and use MPLS for interconnection with other networks.  This document
   offers a simple interconnection approach that may simplify operation
   of DiffServ for network interconnection among providers that use
   MPLS.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-diffserv-intercon/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tsvwg-diffserv-intercon-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-diffserv-intercon-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 23 Mar 2015 06:19:02 +1300

Hi,

I think this draft looks good. I only have a couple of minor comments:

>    In private discussion, the authors of that RFC agree that
>    the proposed interconnection class- and codepoint scheme and its
>    enablement of standardised end to end classes would complement their
>    own work.

Suggestion: rephrase to avoid 'in private discussion', which doesn't
seem to fit in the context of an RFC.

>    RFC 2474's recommendation to forward traffic with unrecognized DSCPs
>    with Default (best effort) service without rewriting the DSCP has
>    proven to be a poor operational practice.

I have to quibble with this remark. As far as I recall, that provision
in RFC 2474 was intended to cover the case of routers *inside* a network
that do not support diffserv or for some reason do not support a
particular DSCP (perhaps due to misconfiguration). The idea was to
provide reasonably robust behaviour for affected packets. That's why the
same paragraph says that unrecognized DSCPs "MUST NOT cause the network
node to malfunction."

It's IMHO orthogonal to the whole question of flows across
diffserv domain boundaries, which are assumed to be re-classified,
re-marked and possibly policed in any case. As RFC 2474 says:
"Differentiated Services Boundary: the edge of a DS domain, where
classifiers and traffic conditioners are likely to be deployed."
I believe that in the diffserv-intercon draft, you should emphasise
that point - if both domains support the interconnection model,
you can bypass full classification and conditioning.

What you *could* say is

 RFC 2474's recommendation to forward traffic with unrecognized DSCPs
 with Default (best effort) service without rewriting the DSCP
 was not intended to apply at differentiated services domain
 boundaries.

Regards
   Brian

---

From: <[email-masked]>
Date: Mon, 23 Mar 2015 09:59:57 +0100

Hi Brian,

thanks for your comment. 

In version -02 I'll change the first section you mention to:

     The authors of that RFC agree that....

Your proposal on an appropriate reference to RFC2474 specifications sounds good to me. If David agrees, we'll replace existing text with it.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: tsvwg [mailto:[email-masked]] Im Auftrag von Brian E Carpenter
Gesendet: Sonntag, 22. März 2015 18:19
An: [email-masked]
Betreff: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-diffserv-intercon-01.txt

Hi,

>    enablement of standardised end to end classes would complement their

Suggestion: rephrase to avoid 'in private discussion', which doesn't seem to fit in the context of an RFC.

>    proven to be a poor operational practice.

I have to quibble with this remark. As far as I recall, that provision in RFC 2474 was intended to cover the case of routers *inside* a network that do not support diffserv or for some reason do not support a particular DSCP (perhaps due to misconfiguration). The idea was to provide reasonably robust behaviour for affected packets. That's why the same paragraph says that unrecognized DSCPs "MUST NOT cause the network node to malfunction."

It's IMHO orthogonal to the whole question of flows across diffserv domain boundaries, which are assumed to be re-classified, re-marked and possibly policed in any case. As RFC 2474 says:
"Differentiated Services Boundary: the edge of a DS domain, where classifiers and traffic conditioners are likely to be deployed."
I believe that in the diffserv-intercon draft, you should emphasise that point - if both domains support the interconnection model, you can bypass full classification and conditioning.

What you *could* say is

 RFC 2474's recommendation to forward traffic with unrecognized DSCPs  with Default (best effort) service without rewriting the DSCP  was not intended to apply at differentiated services domain  boundaries.

Regards
   Brian

---

From: "Black, David" <[email-masked]>
Date: Tue, 24 Mar 2015 16:31:06 +0000

Brian,

> I have to quibble with this remark. As far as I recall, that provision in RFC
> 2474 was intended to cover the case of routers *inside* a network that do not
> support diffserv or for some reason do not support a particular DSCP (perhaps
> due to misconfiguration). The idea was to provide reasonably robust behaviour
> for affected packets. That's why the same paragraph says that unrecognized
> DSCPs "MUST NOT cause the network node to malfunction."

Please look at the "alles in ordnung" discussion in other emails on this draft -
for better or worse, the relevant "running code" preference/practice appears to
be to not have unrecognized DSCPs within a network, and (as Ruediger mentions)
to remark them to something recognized (e.g., bleach to CS0) if/when they show up.

> What you *could* say is
> 
>  RFC 2474's recommendation to forward traffic with unrecognized DSCPs  with
> Default (best effort) service without rewriting the DSCP  was not intended to
> apply at differentiated services domain  boundaries.

I think we could say something like that to better align RFC 2474 and RFC 2475's
recommendations, but dealing with this text in RFC 2474 (and some related text
in RFC 5127) has been source of discussion in working on the diffserv-intercon
draft, so I think some criticism of the bias against DSCP rewriting (in both
RFC 2474 and RFC 5127) is in order ... or "ordnung" ;-).

Thanks,
--David

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Monday, March 23, 2015 5:00 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-diffserv-intercon-01.txt
> 
> Hi Brian,
> 
> thanks for your comment.
> 
> 
> Your proposal on an appropriate reference to RFC2474 specifications sounds
> good to me. If David agrees, we'll replace existing text with it.
> 
> Regards,
> 
> Ruediger
> 
> I have to quibble with this remark. As far as I recall, that provision in RFC
> 2474 was intended to cover the case of routers *inside* a network that do not
> support diffserv or for some reason do not support a particular DSCP (perhaps
> due to misconfiguration). The idea was to provide reasonably robust behaviour
> for affected packets. That's why the same paragraph says that unrecognized
> DSCPs "MUST NOT cause the network node to malfunction."
> 
> It's IMHO orthogonal to the whole question of flows across diffserv domain
> boundaries, which are assumed to be re-classified, re-marked and possibly
> policed in any case. As RFC 2474 says:
> "Differentiated Services Boundary: the edge of a DS domain, where classifiers
> and traffic conditioners are likely to be deployed."
> I believe that in the diffserv-intercon draft, you should emphasise that point
> - if both domains support the interconnection model, you can bypass full
> classification and conditioning.
> 
> What you *could* say is
> 
>  RFC 2474's recommendation to forward traffic with unrecognized DSCPs  with
> Default (best effort) service without rewriting the DSCP  was not intended to
> apply at differentiated services domain  boundaries.
> 
> Regards
>    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Mar 2015 06:23:22 +1300

> to remark them to something recognized (e.g., bleach to CS0) if/when they show up.

Well, yes, if the router in question is fully diffserv aware *and* is
configured for the way diffserv is deployed in that particular domain.
I would agree with "bleaching" in that case. No argument there - please
read my sentence above again. It's talking about default behaviour for
a router that hasn't been configured appropriately.

   Brian