[mpls] Mirja Kühlewind's No Objection on draft-ietf-mpls-rfc4379bis-07: (with COMMENT)

"Mirja Kuehlewind" <ietf@kuehlewind.net> Tue, 25 October 2016 18:17 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: mpls@ietf.org
Delivered-To: mpls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D51531295FD; Tue, 25 Oct 2016 11:17:09 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Mirja Kuehlewind <ietf@kuehlewind.net>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.36.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147741942986.1480.9692706368109608681.idtracker@ietfa.amsl.com>
Date: Tue, 25 Oct 2016 11:17:09 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/FaPlrvonQJStUvtT4wm92RPjnG8>
Cc: draft-ietf-mpls-rfc4379bis@ietf.org, mpls@ietf.org, mpls-chairs@ietf.org
Subject: [mpls] Mirja Kühlewind's No Objection on draft-ietf-mpls-rfc4379bis-07: (with COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Oct 2016 18:17:10 -0000

Mirja Kühlewind has entered the following ballot position for
draft-ietf-mpls-rfc4379bis-07: 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:
https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc4379bis/



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

A few not very important comments:

1) To me it seems a bit unfortunate that this draft points to rfc6425 and
rfc6426 for the definition of the T and R flags, given the goal was to
have all specifications in one doc. Not sure if that can or should be
fixed. Just wanted to mention it.

2) I would expect that the security section recommends border filtering
of MPLS ping message, given that these are usually used within one
domain, no?

3) I know this is a bis doc but I'm still wondering why this TTL trick is
used here. For ICMP that was a way that utilizes the existing
specification and implementation to get further information. However
here, you could just have used a flag in the header either saying 'only
forward to the end' or 'reply and still forward', or something like this,
to cover the two modes. This would also allow to just send one packet to
the end instead of sending one for each hop. Is there a rational for
copying this ICMP hack?