[Idr] Erik Kline's Discuss on draft-ietf-idr-tunnel-encaps-20: (with DISCUSS and COMMENT)

Erik Kline via Datatracker <noreply@ietf.org> Tue, 01 December 2020 05:29 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 65F103A09C4; Mon, 30 Nov 2020 21:29:02 -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.23.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Erik Kline <ek.ietf@gmail.com>
Message-ID: <160680054195.20603.3437170887601694105@ietfa.amsl.com>
Date: Mon, 30 Nov 2020 21:29:02 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/f42qPfKBHYU1P5c7aHwG7-WWY0k>
Subject: [Idr] Erik Kline's Discuss on draft-ietf-idr-tunnel-encaps-20: (with DISCUSS and 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: Tue, 01 Dec 2020 05:29:03 -0000

Erik Kline has entered the following ballot position for
draft-ietf-idr-tunnel-encaps-20: Discuss

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:
https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

[ section 3.3.1 ]

* The text about "[a]ny one-octet value can be transported" leaves me
  wondering about how values that result in ECN bits being set should be
  treated.

  I think there needs to be some recognition here that the DSCP part of
  the octet is only 6 bits (2474 section 3), and that bits 6 & 7 "MUST/SHOULD
  be zero on transmission and MUST/SHOULD be ignored by the recipient".

  Another way to ask the question here is: if ECN is not to be specified as
  part of this octet (and IMHO it should not be), which ranges of 6 bit
  values are permitted: [0..63], with the understanding this will be shifted
  before setting the octet, or [0,4,8,12,...,252]?  Given the text "It
  specifies the setting of the one-octet...", I think it implies the latter,
  but some clarification would, I think, be helpful.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

[[ questions ]]

[ section 3.1 ]

* The prohibition against use of Forwardable=false egress IPs I think means
  that IPv4 and IPv6 link-local addresses cannot be used.  It seems somewhat
  unusual, but not completely outside the realm of reasonable, to have a
  situation where two on-link routers could be configured by their respective
  administrators to use some encapsulation for forwarded packets without
  having to resort to global unicast addresses.

  Are we sure this (odd) use case should be prohibited?

  The final paragraph of this section seems to cover the use of non-reachable
  addresses just fine.  Obviously link-local IPs would need to be exempt from
  section 3.1.1 AS-owned address validation.

[ section 3.3+ ]

* Do any implementations wish to set IPv6 flow labels?

[ section 6 ]

* Might MTU overhead a consideration in tunnel selection?  I.e., given more
  than one tunnel option might an implementation choose based on minimizing
  total overhead?