[tsvwg] draft-ietf-tsvwg-rfc6040update-shim: Suggested Fragmentation/Reassembly text

["Black, David" <[e-mail]>]

Context: Both draft-ietf-tsvwg-rfc6040update-shim and draft-ietf-tsvwg-ecn-encap-guidelines are currently stalled due to incompatibility between the new fragmentation/reassembly text in draft-ietf-tsvwg-rfc6040update-shim and RFC 3168.  Towards getting both drafts moving again ...

This note suggests text to bring Section 5 of draft-ietf-tsvwg-rfc6040update-shim (ECN Propagation and Fragmentation/Reassembly) into alignment with Section 5.3 of RFC 3168 (Fragmentation).   While the existing Section 5 of the rfc6040update-shim draft may be well-intentioned, that draft is not an appropriate vehicle for changing RFC 3168's reassembly requirements.   If those requirements are to be changed, a separate draft focused on fragmentation and reassembly (overall, not just for tunnels) would be appropriate.

For context, here's the crucial text from Section 5.3 of RFC 3168 that the rfc6040update-shim draft needs to align with:

   ECN-capable packets MAY have the DF (Don't Fragment) bit set.
   Reassembly of a fragmented packet MUST NOT lose indications of
   congestion.  In other words, if any fragment of an IP packet to be
   reassembled has the CE codepoint set, then one of two actions MUST be
   taken:

      * Set the CE codepoint on the reassembled packet.  However, this
        MUST NOT occur if any of the other fragments contributing to
        this reassembly carries the Not-ECT codepoint.

      * The packet is dropped, instead of being reassembled, for any
        other reason.

   If both actions are applicable, either MAY be chosen.  Reassembly of
   a fragmented packet MUST NOT change the ECN codepoint when all of the
   fragments carry the same codepoint.

Section 5 of draft-ietf-tsvwg-rfc6040update-shim gets off to a good start - the first two paragraphs of that section are fine and should be retained:


   The following requirements update RFC6040<https://tools.ietf.org/html/rfc6040>, which omitted handling of

   the ECN field during fragmentation or reassembly.  These changes

   might alter how many ECN-marked packets are propagated by a tunnel

   that fragments packets, but this would not raise any backward

   compatibility issues:



   If a tunnel ingress fragments a packet, it MUST set the outer ECN

   field of all the fragments to the same value as it would have set if

   it had not fragmented the packet.

**NEW**: Beyond those first two paragraphs, I suggest deleting the rest of Section 5 of the rfc6040update-shim draft and substituting the following paragraph:


   As a tunnel egress reassembles sets of outer fragments

   [I-D.ietf-intarea-tunnels<https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-09#ref-I-D.ietf-intarea-tunnels>] into packets, it MUST comply with

   the reassembly requirements in Section 5.3 of  RFC 3168 in

   order to ensure that indications of congestion are not lost.

It is certainly possible to continue from that text to paraphrase part or all of Section 5.3 of RFC 3168, but I think the above text crisply addresses the problem, and avoids possibilities of subtle divergence.  I do like the "reassembles sets of outer fragments" lead-in text (which I copied from the current rfc6040shim-update draft) because that text makes it clear that reassembly logically precedes decapsulation at the tunnel egress.

Comments?

Thanks, --David
----------------------------------------------------------------
David L. Black, Senior Distinguished Engineer
Dell EMC, 176 South St., Hopkinton, MA  01748
[phone] New    Mobile: [phone]
[e-mail]<mailto:[e-mail]>
----------------------------------------------------------------