Re: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-spring-lsp-ping-11: (with COMMENT)

"Carlos Pignataro (cpignata)" <> Wed, 11 October 2017 23:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C847132403; Wed, 11 Oct 2017 16:50:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Status: No, score=-14.52 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 JNK71Soxot6W; Wed, 11 Oct 2017 16:50:28 -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 C2AE0134218; Wed, 11 Oct 2017 16:50:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=23230; q=dns/txt; s=iport; t=1507765827; x=1508975427; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6y2ibRNdFze5FBjpi4IwAZ+G9FaqdA65cIJje/NOdoc=; b=Q4YUoCR88xf/m8YlVMncgvSY7Wk3VsUXcDSkMmv1UPCcZW4XJPadlIK9 9Y82we3k8pOrFaeo+4M0sOQH8HUaqBuquDm5cBRn6yvDMnNdPz++ExBE8 nEQHaDw8H5l0pV0Y/ow+4xPDNdx0tkWh4Y7iNgMYVU4qoHve7vyZ3V+x9 s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.43,363,1503360000"; d="scan'208,217";a="306680198"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Oct 2017 23:50:26 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v9BNoPbo021008 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Oct 2017 23:50:26 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 11 Oct 2017 19:50:25 -0400
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Wed, 11 Oct 2017 19:50:24 -0400
From: "Carlos Pignataro (cpignata)" <>
To: Alvaro Retana <>
CC: The IESG <>, "" <>, "" <>, Loa Andersson <>, "" <>
Thread-Topic: Alvaro Retana's No Objection on draft-ietf-mpls-spring-lsp-ping-11: (with COMMENT)
Thread-Index: AQHTQqjyAiDzjFZLukyYl29Xx4kKgaLflSAA
Date: Wed, 11 Oct 2017 23:50:24 +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_0A39065F98164898B83D7F72F49E6AC3ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-spring-lsp-ping-11: (with COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Oct 2017 23:50:30 -0000

Hi, Alvaro,

Thanks for the review! Please see inline.

On Oct 11, 2017, at 11:52 AM, Alvaro Retana <<>> wrote:

Alvaro Retana has entered the following ballot position for
draft-ietf-mpls-spring-lsp-ping-11: 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
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


(1) I’m surprised that there’s not even a passing reference to
draft-ietf-spring-oam-usecase, given that it points to this draft in several
places, among other things as “adding functionality to the use cases described
by this document”.  I'm not advocating for a web of references, just surprised.

Good point and thanks for bringing it up. Will add a small paragraph to the Intro.

Here’s a draft, what do you think?

The mechanics of MPLS LSP Ping as specified in <xref target="RFC8029" />
can be applied to segment routing networks in a Topology-Aware MPLS
Data plane Path Monitoring System (PMS) as shown in
<xref target="I-D.ietf-spring-oam-usecase" />. This document specifies
Target FEC Stacks to further enhance MPLS LSP Traceroute including
control plane validation and tracing to non-SR-capable notes pointed to

(2) The definition of a field with the name “Protocol” in Section 5. (Segment
ID sub-TLV) got me a little confused when I went looking for a registry and
found the values corresponding to the Downstream Detailed Mapping TLV (Section
6).  The name is ok, but I was wondering:  Can you reuse the existing registry
for the values used on the Segment ID sub-TLV?  If so, then the values for
OSPF/ISIS would change.  If not, then please have IANA set one up.

I think I understand this — but, the main Section 5 does not include any “Protocol”.

Sections 5.1, 5.2, and 5.3 do. This is a different Protocol, as you gathered, than the one from the Downstream Mapping in Section 6.

So, we cannot reuse the values for the SID sub-TLVs, because those include things like LDP and RSVP.

However, we can set up a registry for S 5.1, 5.2, and 5.3’s protocol. Like this:

9.2.  Protocol in the Segment ID sub-TLV

   IANA is requested to create a new "Protocol in the Segment ID sub-
   TLV" (see Section 5) registry under the "Multi-Protocol Label
   Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
   registry.  Code points in the range of 0-250 will be assigned by
   Standards Action.  The range of 251-254 are reserved for experimental
   use and will not be assigned.  The initial entries into the registry
   will be:

     Value           Meaning              Reference
   ----------        ----------------     ------------
     0               Any IGP Protocol     This document
     1               OSPF                 This document
     2               ISIS                 This document

(3) What happens if there’s any error (invalid length, unknown protocol, etc.)
in the sub-TLVs defined in Section 5?  I’m assuming that the action is specific
to the TLV that contains them, or that there is something already specified in
rfc8029 — please include a pointer, or specifics if needed.

Nothing different from RFC 8029, which defines Errored TLVs and procedures.

 I see that Section
7.4. (Segment ID Check) says that other values (for Protocol) “MUST be treated
as Protocol value of 0” — that’s ok for now, but when/if other values are used
this document would have to be Updated.  It may be better to say “any other
unassigned value” (or maybe unrecognized, or something along those lines).

Excellent point. Thanks. Will use “unrecognized”.

(4) I would really like to see a registry definition for Adj. Type (in 5.3).

OK, here it goes:

9.3.  Adjacency Type in the IGP-Adjacency Segment ID

   IANA is requested to create a new "Adjacency Type in the IGP-
   Adjacency Segment ID" (see Section 5.3) registry under the "Multi-
   Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping
   Parameters" registry.  Code points in the range of 0-250 will be
   assigned by Standards Action.  The range of 251-254 are reserved for
   experimental use and will not be assigned.  The initial entries into
   the registry will be:

     Value           Meaning
   ----------        ----------------
     0               Unnumbered interface Adjacency
     1               Parallel Adjacency
     4               IPv4, non-parallel Adjacency
     6               IPv6, non-parallel Adjacency