Re: [tsvwg] Adoption call for draft-white-tsvwg-l4sops - to conclude 24th March 2021

[Steven Blake <[e-mail]>]

On Wed, 2021-03-24 at 22:50 +0000, Bob Briscoe wrote:
> Steven,
> 
> 
> On 23/03/2021 00:56, Steven Blake wrote:
> > Sec. 4 (Operator of a Network) of the draft presumes that deployed
> > equipment is capable to classifying packets specifically on ECT(1).
> > Have the authors confirmed that this feature is available on
> > commonly
> > deployed operator gear (e.g., IOS-XR, JUNOS)?
> 
> [BB]
> (Aside: I think you're reading an old (-01) draft. That section has
> been 
> Sec. 5. since draft-02 on 22 Feb 2021.
> See my response to the initial adoption call about the probable cause
> of 
> this confusion - suspected problems with the IETF tools servers.
> )

Oops! You're right. s/Sec. 4/Sec. 5.


> To your point, I checked the manuals of one or two OSs of common
> makes 
> of router before I proposed the WRED technique for addition to the 
> draft. And I discussed the hardware capabilities with people within
> one 
> or two router vendors. In the cases I checked, the CLI limits the 
> flexibility that the admin has to define classifiers as general bit 
> patterns. However the hardware underneath does have that flexibility.
> So 
> this would require a CLI update for the routers I checked. The Linux 
> classifier architecture does provide sufficient flexibility for such
> a 
> classifier.
> 
> I also suggested the ECT(1) tunnel bypass technique, but I didn't 
> exhaustively check the manuals of all the different types of tunnel 
> (there are dozens).
> 
> I think this list of techniques is most useful for router
> developers, 
> who can then find the easiest and most efficient one for their 
> particular kit; whether they have to update the CLI, or whether they
> can 
> find a way for their users to configure their unmodified systems in
> the 
> field.


So operators that *don't wish to participate in L4S experiments* may
need to update *their* deployed software? Ask your favorite router
vendor how many customer-specific releases they are maintaining because
customers don't want to move forward once they get a working validated
release.


Regards,

// Steve