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

[Bob Briscoe <[e-mail]>]

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

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.



Bob

>
>
> Regards,
>
> // Steve
>
>
>
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/