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

From: "Black, David" <[email-masked]>
Date: Tue, 8 Mar 2016 23:07:38 +0000

Digging up a year-old thread ... Ruediger and I are endeavoring to move
diffserv-intercon along ...

> >>>    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."

Well, that may have been the thinking at the time, but that "*inside* a network"
qualification did not make it into RFC 2474, which says only (this is the entire
paragraph):

   Packets received with an unrecognized codepoint SHOULD be forwarded
   as if they were marked for the Default behavior (see Sec. 4), and
   their codepoints should not be changed.  Such packets MUST NOT cause
   the network node to malfunction.

I believe that the original statement is accurate - operators are simply not following
that "SHOULD" but are rather following an "alles in ordnung" approach where the
DSCPs used within a network are only those that are supported by the network (CS0
and DSCPs used for PHBs that the routers support).

Thanks, --David

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Tuesday, March 24, 2015 1:23 PM
> To: Black, David
> Cc: [email-masked]; [email-masked]
> Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-diffserv-intercon-01.txt
> 
> On 25/03/2015 05:31, Black, David wrote:
> > Brian,
> >
> >>>    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."
> >
> > 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.
> 
> 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
> 
> >> 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.
> >>
> >>
> >> 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,
> >>
> >> 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: Brian E Carpenter <[email-masked]>
Date: Wed, 9 Mar 2016 13:27:39 +1300

> and DSCPs used for PHBs that the routers support).

Indeed, that is entirely reasonable practice, but the original words were intended
to make paths via legacy routers or bady configured routers as robust as possible.
In other words the intention was to avoid failures caused by poor operational
practice, not to encourage poor operational practice. 2474 is pretty clear that
rewriting DSCPs at the network boundary is preferred ("Marking is performed by
traffic conditioners at network boundaries,...").

Here's a friendly amendment:

 RFC 2474's recommendation to forward traffic with unrecognized DSCPs
 with Default (best effort) service without rewriting the DSCP has
 proven to be inappropriate in networks that set or verify DSCPs
 at ingress.

That said, I would be very happy to see the document progress rapidly.

  Brian

---

From: "Black, David" <[email-masked]>
Date: Wed, 9 Mar 2016 01:03:30 +0000

> That said, I would be very happy to see the document progress rapidly.

That sounds reasonable.

Thanks,
--David