Subject: [Int-area] Proposal to update RFC 2890 - Key and Sequence Number Extensions to GRE

From: Sabri Berisha <[email-masked]>
Date: Mon, 20 Mar 2017 12:16:09 -0700 (PDT)

Hello IETF workgroup members, 

Apologies if this is sent to the wrong workgroup. 

Recently, I was asked to investigate an issue involving packets being transmitted out of sequence by a flagship routing product of a major vendor of internet backbone routers. Long story short, we observed that the chipset involved would indeed process the frames out of sequence if the following circumstances were met: 

- Small frame size; 
- GRE tunnel with packets with and without the sequence number bit set interleaved; 
- Bursty traffic circumstances (a small frame not carrying the sequence number bit set, arriving within 11 microseconds of a frame with a sequence number set); 

In this case, the key field was populated consistently at all times with the same key identifier. The forwarding chip in this case, took the sequence bit into consideration when determining whether or not it was part of a flow. The vendor addressed the issue by not looking deeper into the frame if the packet is not TCP or UDP. 

Obviously, I found it interesting that a GRE implementation would set the sequence number on some frames in the same flow, but not on others. However, I found that RFC 2890 explicitly allows this in section 2.2: 
"Note that packets without the sequence bit set can be interleaved with packets with the sequence bit set." 
I'm too junior to know the exact reason of why this was allowed, but I'd like to propose an update to RFC 2890, with (apart from all the standard text) the following: 
3. Consistent use of the Key field 
Once the encapsulator elects to insert the Key field for a designated traffic flow, the encapsulator MUST insert the same Key identifier for all frames transmitted as part of that traffic flow. 
4. Consistent use of the Sequence Number field 
Once the encapsulator elects to insert a Sequence Number for a designated traffic flow, the encapsulator MUST insert a Sequence Number for all frames transmitted as part of that traffic flow. 
The encapsulator MUST increment the Sequence Number by 1 for each transmitted frame. The encapsulator MUST NOT interleave frames without the Sequence Number set with frames with the Sequence Number set. 

If ratified as a standard by this working group, it would mandate consistent use of the sequence number fields for the entire duration of a flow. The implementer would make a choice at the initial transmission of the first frame whether or not to use sequence numbers. I have a draft ready, written using the MS Word template, but I thought I'd not poison the inboxes of all subscribers of this mailing list. 

Thanks, 

Sabri