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 <[email protected]>
To: Bob Briscoe <[email protected]>
CC: Margaret Wasserman <[email protected]>, Mahalingam
Mani
<[email protected]>, Dorothy Gellert <[email protected]>,
Michael Montemurro <[email protected]>, Dorothy Stanley
<[email protected]>
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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]>
To: [email protected],
[email protected], [email protected]
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/
