Subject: [tsvwg] Stephen Farrell's No Objection on draft-ietf-tsvwg-diffserv-intercon-12: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 01 Dec 2016 05:58:49 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-tsvwg-diffserv-intercon-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-diffserv-intercon/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- I'm puzzled by this being informational, it sure seems
like something that could/should be a standard. (I'm not
objecting, just puzzled.)

- Section 2: For an IETF consensus document wouldn't it be
good to have some references for claims like "has proven to
be a poor operational practice"? Is that actually a
statement where we're confident of IETF consensus? (I have
no clue, I'm just checking based on the language and the
Informational RFC status.)

---

From: "Black, David" <[email-masked]>
Date: Thu, 1 Dec 2016 15:12:14 +0000

Stephen,

Thanks for the review and interest in this draft.

Diffserv Intercon could become a standard, although I'd really like to see broader operator interest before going there.

On the "bad operational practice" point - the evidence is the widespread operator deployment of "bleaching"
DSCPs to zero at network interconnects.  We could cite RFC 7657, which contains this text in Section 3.2
on that point:

   So, for two arbitrary network endpoints, there can be no assurance
   that the DSCP set at the source endpoint will be preserved and
   presented at the destination endpoint.  Rather, it is quite likely
   that the DSCP will be set to zero (e.g., at the boundary of a network
   operator that distrusts or does not use the DSCP field) or to a value
   deemed suitable by an ingress classifier for whatever network 5-tuple
   it carries.

Would that help?

Thanks, --David

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Thursday, December 01, 2016 8:59 AM
> To: The IESG
> Cc: [email-masked]; Gorry Fairhurst; tsvwg-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Stephen Farrell's No Objection on draft-ietf-tsvwg-diffserv-intercon-12:
> (with COMMENT)
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 1 Dec 2016 15:32:23 +0000

Hi David,

>    deemed suitable by an ingress classifier for whatever network 5-tuple

Not really, but not because it's a bad thing to add:-)

The thing I don't get is whether or not the claim in
the document is something that has IETF consensus or
not. That's because I'm ignorant about that topic, so
I'm just as happy to believe you when you tell me that
it's fine, without text changes.

Cheers,
S.

---

From: "Black, David" <[email-masked]>
Date: Thu, 1 Dec 2016 15:38:53 +0000

Hi Stephen,

We may be talking past each other - the "has proven to be a poor
operational practice" statement is intended to be a "running code"
observation that Joel (OPS AD) should be able to confirm.

If you would like to see "rough consensus" on this, I may need to
dust off my Kevlar (fire-resistant) vest ;-).

Thanks, --David

> Sent: Thursday, December 01, 2016 10:32 AM
> To: Black, David; The IESG
> Cc: [email-masked]; [email-masked]; draft-ietf-tsvwg-diffserv-
> [email-masked]; [email-masked]
> Subject: Re: Stephen Farrell's No Objection on draft-ietf-tsvwg-diffserv-intercon-
> 12: (with COMMENT)
> 
> 
> Hi David,
> 
> > Diffserv Intercon could become a standard, although I'd really like to see
> broader operator interest before going there.
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 2 Dec 2016 08:54:13 +1300

> observation that Joel (OPS AD) should be able to confirm.

As a former diffserv WG chair:

When we put that provision into the original diffserv model, we were
trying to give diffserv a chance of running end to end via ISPs that
didn't support diffserv - effectively by saying that those ISPs would
provide default service for the packets concerned. But in practice,
ISPs that have done anything at all about diffserv (i.e. have not simply
run their routers with factory defaults) have mainly *chosen* to zero
any DSCPs that they don't explicitly support, to prevent unexpected
behaviours. I don't think that statement requires consensus, because it's
a fact.

But "poor" is a judgment call, so Stephen has a point. s/poor/unusual/
would be factual.

    Brian

---

From: "Black, David" <[email-masked]>
Date: Fri, 2 Dec 2016 00:59:55 +0000

> But "poor" is a judgment call, so Stephen has a point. s/poor/unusual/

Sure, or something like "has not been widely deployed in practice."

Thanks, --David

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Thursday, December 01, 2016 2:54 PM
> To: Black, David; Stephen Farrell; The IESG
> Subject: Re: [tsvwg] Stephen Farrell's No Objection on draft-ietf-tsvwg-diffserv-
> intercon-12: (with COMMENT)
> 
> >>>> Subject: Stephen Farrell's No Objection on draft-ietf-tsvwg-diffserv-
> intercon-
> >> 12:
> >>>> (with COMMENT)
> >>>>

---

From: joel jaeggli <[email-masked]>
Date: Thu, 1 Dec 2016 18:12:30 -0800

> Sure, or something like "has not been widely deployed in practice."
The fact that it is in practice unworkable is trivially defensible. It
in fact does not work, My signals are not you signals, and I never
agreed to prioritize your traffic over mine, I don't control the
networks over which my packets flow, Encapsulation makes them invisible
even when I do, the bits are mutable and therefore are recycled, and so
on, it's turtles all the way down.

---

From: <[email-masked]>
Date: Mon, 5 Dec 2016 16:01:48 +0000

Yes,  rewording without judgement is better.

Thanks, Ruediger

-----Ursprüngliche Nachricht-----
Von: Black, David [mailto:[email-masked]] 
Gesendet: Freitag, 2. Dezember 2016 02:00
An: Brian E Carpenter; Stephen Farrell; The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Black, David
Betreff: RE: [tsvwg] Stephen Farrell's No Objection on draft-ietf-tsvwg-diffserv-intercon-12: (with COMMENT)

Thanks, --David

> Cc: [email-masked]; [email-masked]; 
> draft-ietf-tsvwg-diffserv- [email-masked]; [email-masked]
> ISPs that have done anything at all about diffserv (i.e. have not 
> simply run their routers with factory defaults) have mainly *chosen* 
> to zero any DSCPs that they don't explicitly support, to prevent 
> unexpected behaviours. I don't think that statement requires 
> consensus, because it's a fact.
> 
> >> Cc: [email-masked]; [email-masked]; 
> >> draft-ietf-tsvwg-diffserv- [email-masked]; [email-masked]
> >> Subject: Re: Stephen Farrell's No Objection on 
> >> draft-ietf-tsvwg-diffserv-
> intercon-
> >> 12: (with COMMENT)
> >>
> >>
> >> Hi David,
> >>
> >>> On the "bad operational practice" point - the evidence is the 
> >>> widespread
> >> operator deployment of "bleaching"
> >>> DSCPs to zero at network interconnects.  We could cite RFC 7657, 
> >>> which
> >> contains this text in Section 3.2
> >>> on that point:
> >>>
> >> The thing I don't get is whether or not the claim in the document 
> >> is something that has IETF consensus or not. That's because I'm 
> >> ignorant about that topic, so I'm just as happy to believe you when 
> >> you tell me that it's fine, without text changes.
> >>
> >> Cheers,
> >> S.
> >>
> >>>
> >>> Thanks, --David
> >>>
> >>>> Cc: [email-masked]; Gorry Fairhurst; 
> >>>> tsvwg- [email-masked]; [email-masked]; [email-masked]
> >>>> When responding, please keep the subject line intact and reply to 
> >>>> all email addresses included in the To and CC lines. (Feel free 
> >>>> to cut this introductory paragraph, however.)
> >>>>
> >>>>
> >>>> Please refer to 
> >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
> >>>> - I'm puzzled by this being informational, it sure seems like 
> >>>> something that could/should be a standard. (I'm not objecting, 
> >>>> just puzzled.)
> >>>>
> >>>> - Section 2: For an IETF consensus document wouldn't it be good 
> >>>> to have some references for claims like "has proven to be a poor 
> >>>> operational practice"? Is that actually a statement where we're 
> >>>> confident of IETF consensus? (I have no clue, I'm just checking 
> >>>> based on the language and the Informational RFC status.)
> >>>>
> >>>
> >

---

From: Tim Chown <[email-masked]>
Date: Tue, 6 Dec 2016 17:11:33 +0000

> On 2 Dec 2016, at 02:12, joel jaeggli <[email-masked]> wrote:
> 

Well, DSCP transparency was implemented quite widely in NRENs around Europe and on Internet2, but that was several years ago. That was made possible because the European NRENs all work together under one umbrella, GEANT, and they work quite closely with other R&E networks like Internet 2. I remember that we used LBE at our university, and one of the large UK mirror sites marked download traffic as LBE, and the DSCP (8) was transparent on the NREN network (Janet).

Of course as soon as the traffic left the academic networks, all bets were off.

Tim