[lisp] Tsvart telechat review of draft-ietf-lisp-gpe-06
Magnus Westerlund <magnus.westerlund@ericsson.com> Fri, 21 September 2018 10:40 UTC
Return-Path: <magnus.westerlund@ericsson.com>
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 48E4D130E6C; Fri, 21 Sep 2018 03:40:50 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: tsv-art@ietf.org
Cc: lisp@ietf.org, ietf@ietf.org, draft-ietf-lisp-gpe.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153752645024.7431.2528449997753014329@ietfa.amsl.com>
Date: Fri, 21 Sep 2018 03:40:50 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/fCOCxTsHxjNdFQX6fx3LYjMIipU>
Subject: [lisp] Tsvart telechat review of draft-ietf-lisp-gpe-06
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 21 Sep 2018 10:40:50 -0000
Reviewer: Magnus Westerlund Review result: On the Right Track This new version resolved some of the issues, but there are still some issues to resolve. 1. The document is missing the applicability analysis for using UDP zeron checksum to carry either Ethernet or NHS. Each of the incapsulation formats needs an individual analysis. 2. The Ethernet encapsulation and possible also the the NHS needs considerations for congestion control. Where the regular LISP encapuslates only IP, which is assumed to be congestion controlled traffic itself. The same assumption cannot normally be made for Ethernet. So please provide either an argumentation why that would work, or consider what mechanism are needed here to at least prevent that a particular LISP tunnel results in persistent congestion of the path it uses. I would think some type of circuit breaker is appropriate for this usage. I make these comments from the assumption that LISP will be run on top of a multi provider network without guarranted resources, such as the Internet.
- [lisp] Tsvart telechat review of draft-ietf-lisp-… Magnus Westerlund