Subject: [Int-area] Intarea review needed: short draft on ECN propagation IP-shim(s)-IP

From: Bob Briscoe <[email-masked]>
Date: Wed, 31 May 2017 00:08:13 +0100

Intarea list,

I presented this short draft just under a year ago in intarea. Since 
then it has been adopted as a tsvwg work item.

I have just added specific text to update those tunnel specs that are 
under IETF change control (L2TP and GRE), as well as addressing non-IETF 
specs too (VXLAN, GTP, NVGRE etc).

I would appreciate review from someone in intarea who knows these specs 
better than I do.

If you know L2TP well, pls check the l2tpext list, where I have just 
posted three L2TP-specific question.

Cheers

Bob

On 30/05/17 22:49, Bob Briscoe wrote:
> David (as doc shepherd) and the tsvwg list,
>
> As requested, I have added specific text that updates the other 
> relevant RFCs under IETF change control (GRE and L2TP). I have also 
> explained the position in each case for specs not under IETF change 
> control.
>
> I will now go to the relevant WGs (intarea and lt2pext) and ask them 
> to improve my first attempt.
>
> I'll cc you and this list as appropriate.
>
> Cheers
>
>
>
> Bob
>
> PS. I have also said
>
>    the rules in [RFC6040] for
>    propagating the ECN field MUST be applied
>
> whereas before it said "SHOULD". And added an explanation for why 
> "MUST" is appropriate:
>
>    The above is written as a 'MUST' because RFC 6040 allows
>    a compatibility mode for the encapsulator in cases where the
>    decapsulator does not (or cannot) support ECN propagation.
>
>
>
>
>
>
> On 30/05/17 22:36, [email-masked] wrote:
>> A new version of I-D, draft-ietf-tsvwg-rfc6040update-shim-01.txt
>> has been successfully submitted by Bob Briscoe and posted to the
>> IETF repository.
>>
>> Name:        draft-ietf-tsvwg-rfc6040update-shim
>> Revision:    01
>> Title:        Propagating Explicit Congestion Notification Across IP 
>> Tunnel Headers Separated by a Shim
>> Document date:    2017-05-30
>> Group:        tsvwg
>> Pages:        10
>> URL: 
>> https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rfc6040update-shim-01.txt
>> Status: 
>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/
>> Htmlized: 
>> https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-01
>> Htmlized: 
>> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-01
>> Diff: 
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc6040update-shim-01
>>
>> Abstract:
>>     RFC 6040 on "Tunnelling of Explicit Congestion Notification" made 
>> the
>>     rules for propagation of ECN consistent for all forms of IP in IP
>>     tunnel.  This specification extends the scope of RFC 6040 to include
>>     tunnels where two IP headers are separated by at least one shim
>>     header that is not sufficient on its own for packet forwarding.
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of 
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>

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

---

From: Tom Herbert <[email-masked]>
Date: Tue, 30 May 2017 16:51:28 -0700

On Tue, May 30, 2017 at 4:08 PM, Bob Briscoe <[email-masked]> wrote:
> Intarea list,
>
> I presented this short draft just under a year ago in intarea. Since then it
> has been adopted as a tsvwg work item.
>
> I have just added specific text to update those tunnel specs that are under
> IETF change control (L2TP and GRE), as well as addressing non-IETF specs too
> (VXLAN, GTP, NVGRE etc).
>
Hi Bob,

On comment. GRE allows encapsulation of layer 2 (e.g. Ethernet, MPLS,
etc.) and VXLAN only does encapsulation of Ethernet. I don't think
these layer 2 headers could be considered shim headers per the draft,
they are not removed in with the encapsulation headers and are
routable in the layer 2 network. However, the layer 2 packet may
contain an IP packet and in at least once case (VXLAN) there is a
recommendation to apply RFC6040 to an inner IP header.

Maybe the requirements for this scenario should be clarified? I think
it's probably reasonable to say that ECN SHOULD be propagated in this
case.

Tom

> If you know L2TP well, pls check the l2tpext list, where I have just posted
> three L2TP-specific question.
>
>
> Cheers
>
>
> Bob
>
>
>> As requested, I have added specific text that updates the other relevant
>> RFCs under IETF change control (GRE and L2TP). I have also explained the
>> position in each case for specs not under IETF change control.
>>
>> I will now go to the relevant WGs (intarea and lt2pext) and ask them to
>> improve my first attempt.
>>
>> whereas before it said "SHOULD". And added an explanation for why "MUST"
>> is appropriate:
>>
>>>     RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 31 May 2017 02:45:34 +0100

Tom,

On 31/05/17 00:51, Tom Herbert wrote:
> contain an IP packet
You're right in all cases. After posting the draft, I also realized that 
is usually the case with L2TP as well.

One way to include all these cases in the scope of the draft is to say 
the tunnel endpoint SHOULD check the L2 payload for an IP header, even 
when the L2 header is not being added / removed. But that is rather an 
onerous requirement, don't you think? Especially given this would be 
asking the implementer to violate layering, we can only ask that it is 
done when feasible; it cannot be a hard requirement (e.g. L2 payload 
could be encrypted).

> and in at least once case (VXLAN) there is a
What do you mean by "there is a recommendation"? I don't see it in RFC7348?

I am aware that the Linux code for VXLAN does ECN propagation per 
RFC6040. Perhaps that is what you're thinking of?
> it's probably reasonable to say that ECN SHOULD be propagated in this
Yes, overnight I shall mull on how best to rephrase the scope of this, 
without too much mission creep.

Cheers

Bob