[lisp] Roman Danyliw's Discuss on draft-ietf-lisp-6834bis-12: (with DISCUSS and COMMENT)
Roman Danyliw via Datatracker <noreply@ietf.org> Wed, 01 June 2022 18:54 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: lisp@ietf.org
Delivered-To: lisp@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A035C157B47; Wed, 1 Jun 2022 11:54:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-lisp-6834bis@ietf.org, lisp-chairs@ietf.org, lisp@ietf.org, Padma Pillay-Esnault <padma.ietf@gmail.com>, padma.ietf@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 8.3.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <165410969249.3358.8914059517324092461@ietfa.amsl.com>
Date: Wed, 01 Jun 2022 11:54:52 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/iWCWioRYnqCrqIuLB6GB8Wgbj8Q>
Subject: [lisp] Roman Danyliw's Discuss on draft-ietf-lisp-6834bis-12: (with DISCUSS and COMMENT)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.34
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jun 2022 18:54:52 -0000
Roman Danyliw has entered the following ballot position for draft-ietf-lisp-6834bis-12: 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-6834bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- On the -11 document, I initial wrote the following: The SECDIR review by Donald Eastlake asked about handling roll-over/wrap-around of the Map Version Number. Specifically, can a “Map Version Number advance[e] … so quickly that an old version number is encountered that appears to be newer than or equal to the current version number. Why can't this happen? Or if it can, why doesn't that hurt?” It would appear that a number of the conclusions of the ITR or ETR on arriving packets in Section 7.1 and 7.2 wouldn’t be correct. I then saw the -12 document published on June 1 which added the following text to Section 7: Map Version Number incrementing and mappings' TTL MUST be managed so that an old version number will not be confused as a new version number. Thank you for adding this text. Practically, this identifies the desired intent, but doesn’t seem describe the mechanics. Can more be said about how this confusion will be mitigated at the ITR/ETRs? I also don't follow how to use the TTLs here. Consider the situation that Donald noted where the Map Version advanced so quickly that it wraps around so that: (a) the new Map Version Number value equals the old Map Version Number. If one followed the guidance in Section 7.1 of: 1. The packet arrives with the same Dest Map-Version number stored in the EID-to-RLOC Database. This is the regular case. The ITR sending the packet has in its EID-to-RLOC Map-Cache an up-to-date mapping. No further actions are needed. It would seem that the ITR wouldn’t do a Map-Request and would misroute the packet based on the old mapping. (b) the new Map Version Number is now smaller (but in fact fresher/newer) If one followed the guidance of Section 7.1. of: 3. The packets arrive with a Dest Map-Version number smaller (i.e., older) than the one stored in the EID-to-RLOC Database. This means that the ITR sending the packet has an old mapping in its EID-to-RLOC Map-Cache containing stale information. Per bullet #3, if there was wrap-around would the ITR in fact be sending stale mapping information? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Donald Eastlake for the SECDIR review. I support Paul Wouter’s DISCUSS position.
- [lisp] Roman Danyliw's Discuss on draft-ietf-lisp… Roman Danyliw via Datatracker
- Re: [lisp] Roman Danyliw's Discuss on draft-ietf-… Luigi Iannone
- Re: [lisp] Roman Danyliw's Discuss on draft-ietf-… Alvaro Retana
- Re: [lisp] Roman Danyliw's Discuss on draft-ietf-… Roman Danyliw