Re: [tsvwg] Robert Wilton's No Objection on draft-ietf-tsvwg-rfc6040update-shim-21: (with COMMENT)

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Bob,

Please see inline …

From: Bob Briscoe <[e-mail]>
Sent: Friday, December 1, 2023 11:31 PM
To: Rob Wilton (rwilton) <[e-mail]>; The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [tsvwg] Robert Wilton's No Objection on draft-ietf-tsvwg-rfc6040update-shim-21: (with COMMENT)

Robert, Thank you for these thoughts. Pls see [BB]
On 24/11/2023 13:06, Robert Wilton via Datatracker wrote:

Robert Wilton has entered the following ballot position for

draft-ietf-tsvwg-rfc6040update-shim-21: 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/about/groups/iesg/statements/handling-ballot-positions/

for more information about how to handle DISCUSS and COMMENT positions.





The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/







----------------------------------------------------------------------

COMMENT:

----------------------------------------------------------------------



Hi,



Thanks for this document, I found it interesting to read.  A couple of minor

comments for you to consider:



(1) p 5, sec 4.  Making a non-ECN Tunnel Ingress Safe by Configuration



      Whether or not an ingress implementation claims compliance with

      RFC 6040, RFC 4301 or RFC3168, when the outer tunnel header is IP

      (v4 or v6), if possible, the operator MUST configure the ingress

      to zero the outer ECN field in any of the following cases:



As a minor comment, I wonder whether RFCs should be specifying requirements on

people (i.e., operators), or whether it would be better to place the

requirement on the deployment.

[BB] We (the WG) had to work out how to navigate this particularly tricky balancing act. The following paras at the end of §3 were intended to explain:
However, the ECN field is a non-optional part of the IP header (v4 and v6). So any implementation that creates an outer IP header has to give the ECN field some value. There is only one safe value a tunnel ingress can use if it does not know whether the egress supports propagation of the ECN field; it has to clear the ECN field in any outer IP header to 0b00.

However, an RFC has no jurisdiction over implementations that choose not to comply with it or cannot comply with it, including all those implementations that predated the RFC. Therefore it would have been unreasonable to add such a requirement to RFC 6040. Nonetheless, to ensure safe propagation of the ECN field over tunnels, it is reasonable to add requirements on operators, to ensure they configure their tunnels safely (where possible).

Perhaps your suggestion has taken this all into account, so you're suggesting that placing the requirement on the deployment would be better than on the operator (of the deployment). Perhaps, but I always prefer the active to the passive. "A deployment of an ingress SHOULD be configured to zero the outer," is less clear than, "The operator SHOULD configure the ingress to zero the outer."
[Rob Wilton (rwilton)]

I was perhaps thinking of something more like:


                    if possible, the ingress device SHOULD be configured to

        zero the outer ECN field in any of the following cases:

This text has the benefit of applying no matter how the configuration came into effect, e.g., perhaps it is being configured via a controller, or even as part of a configuration template produced by a controller manufacturer.


FWIW, I'm not sure what the problem is with placing requirements on people. I've seen drafts 'corrected' when they place requirements on implementers, rather than implementations. But is this practice actually documented anywhere, or is there any rationale to support it? I'm always willing to learn if there is.

[Rob Wilton (rwilton)]
Placing the requirement on the person seems to unnecessarily constrain compliance to only where a person is actively involved in the process.  Is that the goal here?  I.e., does the requirement still apply if the action is being taken by a machine, code, or some other automation?

Ultimately, I think that it doesn’t matter who takes the action, what really matters is how the protocol behaves and hence that is why I believe that it is more precise to place the constraints on the required resultant effect, not on the person/action to achieve that effect.

But this is also a non-blocking comment.  I.e., you can keep the text in the active tense if you wish, and I suspect folks will manage to infer the actual underlying intent.





(2) p 10, sec 6.1.1.  L2TP (v2 and v3) ECN Extension



   L2TP maintainers are RECOMMENDED to implement the ECN extension to

   L2TPv2 and L2TPv3 defined in Section 6.1.1.2 below, in order to

   provide the benefits of ECN [RFC8087], whenever a node within an L2TP

   tunnel becomes the bottleneck for an end-to-end traffic flow.



Similarly to my previous comment, should the RFC 2119 requirement be placed on

the maintainers, or should it be placed on an updated versions of L2TP?

[BB] Here, I agree with you. Proposed replacement text:



   Implementation of the ECN extension to L2TPv2 and L2TPv3 defined in Section

   6.1.1.2 below is RECOMMENDED, in order to provide the benefits of ECN...

Similarly, with the identically structured requirements in the GRE and AMT sections.

Thank you.


Bob

[Rob Wilton (rwilton)]
Regards,
Rob







Regards,

Rob









--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/