Re: [tsvwg] New Version Notification for draft-heist-tsvwg-ecn-deployment-observations-02.txt

[Gorry Fairhurst <[e-mail]>]

On 09/03/2021 16:33, [e-mail] wrote:
> Gorry, Jonathan, tsvwg
>
> See below  [AB]
>
> On Tuesday, March 9, 2021, 4:18:23 PM GMT, Gorry Fairhurst 
> <[e-mail]> wrote:
>
>
> On 09/03/2021 15:44, Jonathan Morton wrote:
> >> On 9 Mar, 2021, at 5:42 pm, Gorry Fairhurst <[e-mail] 
> <mailto:[e-mail]>> wrote:
> >>
> >> I understand that to say: if a router wishes to be compatable with 
> L4S, this is one way to do this. The recommendation(s) could be 
> stronger, if the community thinks this is what is needed.
> > As I tried to point out in my talk, the problem is that a great many 
> people are already running RFC-3168 compliant AQMs with no knowledge 
> of L4S and, therefore, no "wish to be compatible" with a new spec that 
> explicitly violates the spec they built against.
> >
> > Myself included.
> >
> >  - Jonathan Morton
>
> This is pecisely why we have a standards process to make this change.
> When the work on L4S was first brought to the IETF, I know many people
> weighed the prospects of replacing the RFC3168 behavior.
>
> When the L4S specs are published, this will indeed be a disruptive
> change for some, and people deploying and implementing do need to
> consider this. The place to describe this might be in
> draft-white-tsvwg-l4sops within the tsvwg, if this is adopted (this
> adoption call is on-going currently on the tsvwg list).
>
> [AB] Not sure it's a problem, but rfc8311 (sec 4.2) says variation of 
> marking behavior between ECT(0) and ECT(1) must be specified in an 
> experimental RFC. The ops call just made for draft-white-tsvwg-l4sops 
> is to be an informational RFC.
>
> With hindsight, I'm not sure why rfc8311 (which is standards track) 
> didn't deprecate marking ECT(1) the same way it deprecated endpoints 
> using it, outside experiments.
>
>
> Alex
>
Thanks Alex,

I noted that.

Let's see if there is WG consensus to support the OPS draft for L4S.

If you think we need RFC 2119 language to express the intention of the 
draft, then we'll certainly take this into consideration after the WG 
adopts the ID. we'll figure out the standards status for this document - 
this is largely a Chairs role to steer the documentation/recommendations 
to the appropiate specs, but one where we do appreciate input!

Gorry