Re: [L2tpext] Propagating IP/ECN field when L2TP sits between IP as both L2 payload and PSN

[Ignacio Goyret <[e-mail]>]

At 15:11 5/31/2017, Bob Briscoe wrote:

>>I do not understand however why "Update", or what that implies to
>>a compliant implementation. Many features of L2TP are specified in
>>various WGs, not "Updating" the base specs.
>> 
>By my understanding of the word extension, if a implementation that
>is compliant with RFC3931 does not implement an extension, it is
>still compliant with RFC3931. Is this how the word "extension" is
>used in L2TP land?
>
>Whereas, if one IP header encapsulates another, if the ECN field
>were processed in any way other than RFC6040, it would be invalid
>(unless another RFC were written to update RFC6040). Therefore,
>whenever L2TP is tunnelling IP in IP, it is mandatory to comply
>with RFC6040. So I am asking the L2TPext WG for advice on how you
>guys would make a mandatory update to L2TP, rather than 'just' an
>optional extension.

I'm not sure you will get much traction for a "mandatory" update
because it would immediately invalidate any compliant deployed code
out there.

This goes back to the question of why negotiate it if it is mandatory.

Real life says that there will be some L2TP deployments that will
support ECN and some that won't, thus, the negotiation is needed
to maintain interoperability.

But if the negotiation is required, then this can't be an update
since it must allow for LCCEs that don't support ECN (which it must,
because some deployments may choose (or may have to) stay with
their non-ECN supporting code for a variety of reasons).

Yes, I know: it is sort of a circular argument but hopefully you
see what I mean.

-Ignacio