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

[Tom Herbert <[e-mail]>]

On Tue, May 30, 2017 at 4:08 PM, Bob Briscoe <[e-mail]> 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

> 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, [e-mail] 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/
>
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area