Re: [secdir] Review of draft-ietf-mpls-entropy-lsp-ping-04

"Carlos Pignataro (cpignata)" <> Thu, 01 September 2016 15:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B346112DA2C for <>; Thu, 1 Sep 2016 08:15:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.048
X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3W0RpWfVv7d1 for <>; Thu, 1 Sep 2016 08:15:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A760312DA38 for <>; Thu, 1 Sep 2016 08:15:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=6800; q=dns/txt; s=iport; t=1472742908; x=1473952508; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=k4OLA8SSXPMNaj9IyURCVj9A+mt1E27NpZSt0GTYtPs=; b=bvIn75pQW0fKsUOeI9T/htWqggQcDwYvSmopbitni/O0RYDtlWRReFym q9pdHyLei6LHOr9PEry/wV3ECq48lfMcabOUYgQI6YdA37mbfFFiuU6AU 84/Y1SnSuFqQ5XgTR0LxTqSfjPfOBtkXPSrGPtkUOjYPxIB0dXgnvTw2B A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.30,268,1470700800"; d="scan'208,217";a="142442824"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Sep 2016 15:15:07 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u81FF72G001145 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Sep 2016 15:15:07 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 1 Sep 2016 11:15:06 -0400
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Thu, 1 Sep 2016 11:15:06 -0400
From: "Carlos Pignataro (cpignata)" <>
To: "Andrew G. Malis" <>
Thread-Topic: Review of draft-ietf-mpls-entropy-lsp-ping-04
Thread-Index: AQHSAjNlgOV36X1rzE2hxO8HBsuHYaBh0kEAgAMzowA=
Date: Thu, 01 Sep 2016 15:15:06 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D82BC29335C148C69AB38E71F22985E6ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [secdir] Review of draft-ietf-mpls-entropy-lsp-ping-04
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Sep 2016 15:15:15 -0000

Dear Shawn,

Thanks again — just closing the loop, all fixed in our working copy.

— Carlos.

On Aug 30, 2016, at 10:21 AM, Andrew G. Malis <<>> wrote:


Many thanks for your review. We’ll fix the editorial comment. Regarding LSP stitching, this is well known to MPLS experts, but you’re right, this should be referenced. RFC 6424, which we already have in the references, is an excellent reference for LSP stitching and using LSP Ping and Traceroute over stitched LSPs. We’ll add [RFC6424] in the appropriate locations.

Thanks again,

On Tue, Aug 30, 2016 at 4:26 AM, Shawn M Emery <<>> wrote:

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors. Document editors and WG chairs should treat these
comments just like any other last call comments.

This draft specifies multipath support in environments where Entropy Labels
(ELs) are used so that Label Switched Path (LSP) Ping and Traceroute
operations are possible.

The security considerations section does exist and refers to the security
considerations in base specifications for applicability.  The sections
continues that there are no new security considerations with
this specification.  I agree with this assertion.

General comments:


Editorial comments:

s/initiator to not be able to/initiator that is unable to/

"LSPs stitched together": not for sure what "stitched" means and wasn't
defined in the Terminology section.