[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.