[Idr] Erik Kline's No Objection on draft-ietf-idr-tunnel-encaps-22: (with COMMENT)

Erik Kline via Datatracker <noreply@ietf.org> Sun, 10 January 2021 06:55 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 541443A0CD6; Sat, 9 Jan 2021 22:55:57 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Erik Kline via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-idr-tunnel-encaps@ietf.org, idr-chairs@ietf.org, idr@ietf.org, John Scudder <jgs@juniper.net>, aretana.ietf@gmail.com, Susan Hares <shares@ndzh.com>, shares@ndzh.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Erik Kline <ek.ietf@gmail.com>
Message-ID: <161026175703.25734.15940517066675592074@ietfa.amsl.com>
Date: Sat, 09 Jan 2021 22:55:57 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/36cZqNcnz24qKZU-QSxt29QSh-s>
Subject: [Idr] Erik Kline's No Objection on draft-ietf-idr-tunnel-encaps-22: (with COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Jan 2021 06:55:57 -0000

Erik Kline has entered the following ballot position for
draft-ietf-idr-tunnel-encaps-22: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


[ section 3.3.1 ]

https://www.rfc-editor.org/rfc/rfc2474.html#section-3 says this about the term
"DS field":

   Six bits of the DS field are used as a codepoint (DSCP) to select the
   PHB a packet experiences at each node.  A two-bit currently unused
   (CU) field is reserved and its definition and interpretation are
   outside the scope of this document.  The value of the CU bits are
   ignored by differentiated services-compliant nodes when determining
   the per-hop behavior to apply to a received packet.

   The DS field structure is presented below:

        0   1   2   3   4   5   6   7
      |         DSCP          |  CU   |

        DSCP: differentiated services codepoint
        CU:   currently unused

So, if this section 3.3.1 one byte DS field is meant to be the same (i.e.
includes the 2 CU bits that are now ECN bits), then I'm good with this.