Re: [OPSAWG] Update to RFC5415 (ex draft-ietf-capwap-protocol-specification)?

[Bob Briscoe <[e-mail]>]

Joe and other opsawg-chairs
Authors of draft-ietf-opsawg-capwap-alt-tunnel
Chairs of CAPWAP ex-WG
Authors of original CAPWAP spec [RFC5415]

As promised, I have posted a new rev of 
draft-ietf-tsvwg-rfc6040update-shim-02
Pls review/comment.
I am not on the opsawg list, so pls include my email explicitly.

It is planned to WGLC in tsvwg by Sep 2017.
Pls tell the doc Shepherd (David Black, in cc) if you still want it 
WGLC'd in opsawg too.

Having written it, I discovered it actually doesn't need to update the 
CAPWAP spec. Even though the way negotiation of ECN modes work has 
changed [RFC6040], it's written in a way that's backward compatible with 
negotiation of the old ECN [RFC3168] that CAPWAP referred to. So I ended 
up deleting all the text I wrote about it, and just referring to RFC6040.

Nonetheless, for draft-ietf-opsawg-capwap-alt-tunnel you will want to 
know that this updates L2TP and GRE.
If you still want me to give a 5min heads-up in opsawg in Prague, just say.

Cheers


Bob



On 15/06/17 13:42, Bob Briscoe wrote:
> Joe,
>
> Thanks, and thanks to everyone on the trail to reach you.
>
> I hope to complete the new rev of the draft today, so I'll email a 
> notification to the authors you suggest and the opsawg list.
>
> Yes, pls consider this for a 5min heads-up slot in opsawg in Prague.
> Title: Propagating ECN Across IP Tunnel Headers Separated by a Shim
> Draft: draft-ietf-tsvwg-rfc6040update-shim
> Duration: 5 mins
> Presenter: Bob Briscoe
>
>
> The co-authors of capwap-alt-tunnel will definitely be a group that 
> will be interested - thanks for that. I guess less so for RFC7494, but 
> at least these are people recently interested in CAPWAP.
>
>
>
>
> Bob
>
> On 14/06/17 15:02, Joe Clarke wrote:
>> On 6/14/17 08:04, Benoit Claise wrote:
>>> Bob, Margaret,
>>>
>>> Thanks for checking.
>>> The latest CAPWAP work was done in OPSAWG.
>>> See RFC7494 and
>>> https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/
>>>
>>> So it makes sense to LC the draft in OPSAWG, next to TSVWG.
>>> At the minimum, you want to get feedback from the authors of those two
>>> documents
>>> The OPSAWG chairs are copied.
>>> Presenting in OPSAWG is also an option IMO.
>> I agree with Benoit that doing an LC in opsawg makes sense. Ahead of
>> that, it would be good to send an email to opsawg@ (as well as the
>> authors of draft-ietf-opsawg-capwap-alt-tunnel and RFC7494) to get more
>> eyes on the text.  If there is to be a presentation, having people clued
>> in ahead of time would be useful; plus any discussion can be addressed
>> directly.
>>
>> In particular, you have questions regarding implementations and full
>> ECN, so understanding the landscape would be a very useful thing.
>>
>> Joe
>>
>>> Regards, B.
>>>
>>>> Benoit, Warren,
>>>>
>>>> I am about to write text into a draft adopted in tsvwg that updates
>>>> the ECN section of the CAPWAP protocol spec [RFC5415]. See the email
>>>> starting this thread below for details.
>>>>
>>>> Please advise:
>>>> * whether you would like the draft last called in the ops-area WG as
>>>> suggested by Margaret below.
>>>> * to which mailing list(s) you would like me to forward announcements
>>>> of draft revisions.
>>>> * whether you would like me to present a brief heads-up in any
>>>> ops-area session in Prague (I am sure you could do a heads-up 
>>>> without me).
>>>>
>>>> [Margaret, Michael, thanks for your responses]
>>>>
>>>> Cheers
>>>>
>>>>
>>>> Bob
>>>>
>>>>
>>>> -------- Forwarded Message --------
>>>> Subject:     Re: Update to RFC5415 (ex
>>>> draft-ietf-capwap-protocol-specification)?
>>>> Date:     Mon, 12 Jun 2017 13:03:52 -0400
>>>> From:     Margaret Cullen <[e-mail]>
>>>> To:     Bob Briscoe <[e-mail]>
>>>> CC:     Margaret Wasserman <[e-mail]>, Mahalingam 
>>>> Mani
>>>> <[e-mail]>, Dorothy Gellert <[e-mail]>,
>>>> Michael Montemurro <[e-mail]>, Dorothy Stanley
>>>> <[e-mail]>
>>>>
>>>>
>>>>
>>>> I don’t object to the update.  I agree with making it as small as
>>>> possible.
>>>>
>>>> I am not sure that the main protagonists of CAPWAP are all still
>>>> active in the IETF, and there is no current WG responsible for
>>>> maintaining the document.  You might want to talk to the OPS ADs, and
>>>> see if they would like to LC the CAPWAP changes in the ops-area WG.
>>>>
>>>> Margaret
>>>>
>>>> On 12/06/17 17:17, Michael Montemurro wrote:
>>>>> Bob,
>>>>>
>>>>> Thanks. I don’t have any issues with updating the ECN text. In my
>>>> opinion, I would just add the support minimally. I would not recommend
>>>> playing with specifying mandatory behavior.
>>>>> Cheers,
>>>>>
>>>>> Mike
>>>>> On Jun 12, 2017, at 9:08 AM, Bob Briscoe <[e-mail]
>>>>> <mailto:[e-mail]>> wrote:
>>>>>
>>>>> Margaret, Mahalingam, Dorothy, Michael, Dorothy,
>>>>>
>>>>> I've not seen a reply to the email below, so I'm adding the ex-chairs
>>>>> of the original CAPWAP WG.
>>>>> I need help finding which current WG is responsible for maintaining
>>>>> this RFC and finding the current email @s of the main protagonists.
>>>>>
>>>>> Cheers
>>>>>
>>>>>
>>>>> Bob
>>>>>
>>>>> -------- Forwarded Message --------
>>>>> Subject:     Update to RFC5415 (ex
>>>>> draft-ietf-capwap-protocol-specification)?
>>>>> Date:     Mon, 5 Jun 2017 14:44:47 +0100
>>>>> From:     Bob Briscoe <[e-mail]>
>>>>> To:     [e-mail],
>>>>> [e-mail], [e-mail]
>>>>>
>>>>>
>>>>>
>>>>> Pat, Michael, Dorothy, [I think I have got Michael and Dorothy's
>>>>> emails, but I couldn't find a recent one for Pat, so pls forward]
>>>>>
>>>>> In 2010, a year after RFC 5415 was published, the sections on ECN
>>>>> were effectively updated by RFC6040, which made some subtle but
>>>>> important changes to IP-in-IP tunnelling of ECN.
>>>>>
>>>>> RFC6040 updated RFC3168, which RFC5415 refers to normatively. By a
>>>>> lazy interpretation of the IETF process there is nothing to do,
>>>>> because RFC5415 automatically refers to any update of RFC3168.
>>>>> Nonetheless, there is no text to say how a CAPWAP implementation
>>>>> ought to work with the new ECN tunnelling in RFC6040.
>>>>>
>>>>> I am in the process of revising a draft chartered in tsvwg.
>>>>> https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-01
>>>>> In the next rev it will clarify that shim headers (like CAPWAP)
>>>>> between an IP outer and a L2 inner that contains an inner IP header
>>>>> as payload are within scope of RFC6040.
>>>>>
>>>>> I was intending to include CAPWAP in the list of protocols that
>>>>> already encapsulate ECN correctly. However, the ECN text in RFC5415
>>>>> is not quite right for the updated way that ECN tunnelling is 
>>>>> specified.
>>>>>
>>>>> Do you want this new draft to update the CAPWAP ECN text?
>>>>>
>>>>> We could:
>>>>> * either do this minimally,
>>>>> * or (if most current implementations support ECN anyway) we could go
>>>>> further and somehow make ECN support mandatory as long as we don't
>>>>> make any existing CAPWAP implementations non-compliant. RFC5415
>>>>> already aspires to this at the end of Section 14:
>>>>>     Future versions of the CAPWAP protocol should consider mandating
>>>>>     support for the "full functionality option".
>>>>> The rest of this email gives you background, to save having to read
>>>>> the full RFCs.
>>>>>
>>>>>
>>>>> *Background**to RFC6040 relevant to CAPWAP
>>>>> *
>>>>> RFC 5415 refers normatively to RFC 3168 for ECN tunnelling.
>>>>> RFC6040 introduced two main changes to RFC3168 (all the normative
>>>>> text is in Section 4
>>>>> <https://tools.ietf.org/html/rfc6040#section-4>), summarized here:
>>>>>
>>>>> *Decap: **
>>>>> ** MUST implement decap behaviour to claim compliance with RFC6040
>>>>>      (RFC5415 does not comply with this, because ECN decap behaviour
>>>>> is not mandatory)
>>>>> * Minor changes to decap behaviour to:
>>>>>    + add handling of unexpected combinations of inner and outer ECN
>>>>> field to cater for bugs on upstream network nodes
>>>>>
>>>>> *Encap: **
>>>>> *
>>>>> * Different modes: Instead of the old Limited and Full Functionality
>>>>> modes (of the whole tunnel), there's only one mode at decap, but two
>>>>> modes at encap:
>>>>>    + compatibility mode (zero the outer ECN): same as the old limited
>>>>> compatibility mode, but ingress only
>>>>>    + normal mode (copy inner ECN to outer, slightly different to the
>>>>> old full functionality mode, to bring all IP-in-IP tunnelling into
>>>>> line with the previous IPsec ingress behaviour)
>>>>>
>>>>> * Ingress MUST check that egress supports any current or previous ECN
>>>>> decap RFCs before using normal mode
>>>>>      *(**Primary safety requirement to prevent congestion signals
>>>>> being black-holed at egress)*
>>>>>      (CAPWAP already complies)
>>>>>
>>>>> * Ingress MUST implement both compatibility and normal modes to 
>>>>> comply
>>>>>      (CAPWAP doesn't currently comply, but the above quote from
>>>>> section 14 aspires to this)
>>>>>
>>>>>
>>>>> *Background**to ECN Support in RFC5415 on CAPWAP
>>>>> *
>>>>> RFC5415 discusses ECN in the following sections (I have quoted
>>>>> relevant extracts of normative text):
>>>>>
>>>>> * 4.5.2.  Quality of Service
>>>>> <https://tools.ietf.org/html/rfc5415#section-4.5.2>
>>>>>     CAPWAP ACs and WTPs SHALL implement the limited
>>>>>     functionality and are RECOMMENDED to implement the full 
>>>>> functionality
>>>>>     described in [RFC3168 <https://tools.ietf.org/html/rfc3168>].
>>>>> * 4.6.25 ECN Support 
>>>>> <https://tools.ietf.org/html/rfc5415#section-4.6.25>
>>>>>
>>>>> ECN Support message element
>>>>>        0 -  Limited ECN Support
>>>>>        1 -  Full and Limited ECN Support
>>>>> * 6.1.  Join Request 
>>>>> <https://tools.ietf.org/html/rfc5415#section-6.1>
>>>>>     The following message elements MUST be included in the Join 
>>>>> Request
>>>>>     message.
>>>>>    [...]
>>>>>     o  ECN Support, see Section 4.6.25 
>>>>> <https://tools.ietf.org/html/rfc5415#section-4.6.25>
>>>>> * 14.  Transport Considerations
>>>>> <https://tools.ietf.org/html/rfc5415#section-14>
>>>>>     The CAPWAP protocol mandates support of the Explicit Congestion
>>>>>     Notification (ECN) through a mode of operation named "limited
>>>>>     functionality option", detailed in section 9.1.1 of [RFC3168]
>>>>> <https://tools.ietf.org/html/rfc3168#section-9.1.1>.
>>>>>     Future versions of the CAPWAP protocol should consider mandating
>>>>>     support for the "full functionality option".
>>>>> * 15.  IANA Considerations
>>>>> <https://tools.ietf.org/html/rfc5415#section-15>
>>>>>     15.16.  ECN Support
>>>>> <https://tools.ietf.org/html/rfc5415#section-15.16>
>>>>>     The values zero (0) and one (1) are
>>>>>     allocated in this specification, and can be found in Section 
>>>>> 4.6.25 <https://tools.ietf.org/html/rfc5415#section-4.6.25>.
>>>>>
>>>>> Regards
>>>>>
>>>>>
>>>>> Bob
>>>>>
>>>>>
>>>>> -- 
>>>>> ________________________________________________________________
>>>>> Bob Briscoe http://bobbriscoe.net/
>

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