Skip to main content

Tunnelling of Explicit Congestion Notification
draft-ietf-tsvwg-ecn-tunnel-10

Yes

(David Harrington)

No Objection

Lars Eggert
(Alexey Melnikov)
(Dan Romascanu)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Tim Polk)

Note: This ballot was opened for revision 10 and is now closed.

Lars Eggert
No Objection
David Harrington Former IESG member
Yes
Yes () Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2010-08-25) Unknown
A quick note.
In the Acknowledegements...

   The views expressed here are those of the
   author only.

I know what you mean with respect to your sponsor, but the views expressed here represent IETF consensus now, so this sentence is not accurate.
Alexey Melnikov Former IESG member
No Objection
No Objection () Unknown

                            
Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (2010-08-25) Unknown
A few comments from Ari Keranen:

1. Introduction

   Nonetheless, the latest IPsec architecture [RFC4301] considered a
   bandwidth limit of 2 bits per packet on a covert channel made it a
   manageable risk.

Remove "made it"?

4. New ECN Tunnelling Rules

   an alternate congestion marking scheme used by a specific Diffserv
   PHB (see S.5 of [RFC3168] and [RFC4774]).

For consistency: s/S/Section/
(also in Section 7 and Appendix B1)
Robert Sparks Former IESG member
(was No Record, No Objection) No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Sean Turner Former IESG member
(was Discuss, No Objection) No Objection
No Objection (2010-08-25) Unknown
A fine document.  I've only got some non-blocking comments:

#1 - Sometimes RFC4301 and RFC3168 is used when describing the IPsec tunnels and non-IPsec tunnels and sometimes it is used to describe the actual document.  Could IPsec tunnels and non-IPsec tunnels be used instead when discussing the tunnels and [RFC4301] and [RFC3168] be used when describing the document?  I think it would make it clearer.

#2 - If there's one required mode and one optional, then I suggest in Section 4.1:

OLD:

a REQUIRED `normal mode' and a `compatibility mode'

NEW:

a REQUIRED `normal mode' and an OPTIONAL `compatibility mode'

#3 - The tables include codepoints and "drop". Can you add a NOTE that indicates "drop" in the tables is not a codepoint.

#4 - Section 4.2: 

 This is because the
 inner Not-ECT marking is set by transports that use drop as an
                                                         
                                    replace drop with "drop" ?

  indication of congestion and would not understand or respond to
  any other ECN codepoint [RFC4774].

#5 - Section 5.1 & 5.2, please indicate which sections are changed in 4301/3168.  It will aid readers who are familiar with those documents.   

#6 - Section 5.2:

The compatibility mode of encapsulation is identical to the
      encapsulation behaviour of the limited functionality mode of an
      RFC3168 ingress, except it is optional.
                                    ^^^^^^^^r/optional/OPTIONAL?
Stewart Bryant Former IESG member
No Objection
No Objection (2010-08-24) Unknown

> In some circumstances (e.g. pseudowires, PCN), the whole path
> is divided into segments, each with its own congestion
> notification and feedback loop. 

The above reference to PWs assumes an agreed  documented MS-PW congestion architecture, whereas the most that exists is a few hints in RFC5659. The reference to PWs should be removed, or the text aligned with RFC5659.



Tim Polk Former IESG member
No Objection
No Objection () Unknown