[I2nsf] Magnus Westerlund's Discuss on draft-ietf-i2nsf-sdn-ipsec-flow-protection-12: (with DISCUSS)

[Magnus Westerlund via Datatracker <[e-mail]>]

Magnus Westerlund has entered the following ballot position for
draft-ietf-i2nsf-sdn-ipsec-flow-protection-12: Discuss

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-i2nsf-sdn-ipsec-flow-protection/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

        leaf ecn {
          type boolean;
          default false;
          description
            "Explicit Congestion Notification (ECN). If true
            copy CE bits to inner header.";
          reference
            "Section 5.1.2 and Appendix C in RFC 4301.";
        }

There is something wrong here, likely in the description of the option. This as
the outer IP header on sender side needs to set ECN field to ECT to enable so
that any CE marks can be received. I think it is reasonable to have an option
to just enable ECN, but that requires several things. Secondly with the changes
in RFC 8311, there might be need to be more explicit in the configuration of
ECN to actually indicate which ECT value that should be set on send side for
the established IPsec tunnel. Due to under discussion experiments with ECT
values per RFC 8311 we should verify that just copying the inner header value
to the external is fine and don't break anything as path and/or marking
behavior may not be the same.

I think there is also the question if RFC 6040 needs to be referenced in this
context to ensure that people pick up on that RFC 6040 updates RFC 4301.