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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C51B7132198; Wed, 11 Oct 2017 16:04:50 -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_H4=-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 DmklbZxZv0xj; Wed, 11 Oct 2017 16:04:44 -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 CD970132025; Wed, 11 Oct 2017 16:04:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=16730; q=dns/txt; s=iport; t=1507763083; x=1508972683; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gZpcWZYMdDjQJzs93/d3ijnhL5A9aoGQ0dGAK1dKb9A=; b=h+MxlkF+TdXsKOck/Op7FAkjPfFmQMWw2w5WRnUExldPfehJApw/x2l7 96RZk97rYzN5GpZI8+78JRfWheO347ZSzwsurw6wQyKivpSrBOyWjIDpm fRo9ydq0ZE1cHyZI/u2tO9AhiFVGLhyF7bK45RJHJrh/7SNt5IJdcvv1w E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.43,363,1503360000"; d="scan'208,217";a="310301384"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Oct 2017 23:04:42 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v9BN4gYm013742 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Oct 2017 23:04:42 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 11 Oct 2017 19:04:41 -0400
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Wed, 11 Oct 2017 19:04:41 -0400
From: "Carlos Pignataro (cpignata)" <>
To: Spencer Dawkins <>
CC: The IESG <>, "" <>, Loa Andersson <>, "" <>, "" <>
Thread-Topic: Spencer Dawkins' No Objection on draft-ietf-mpls-spring-lsp-ping-11: (with COMMENT)
Thread-Index: AQHTQjWPQQPmtoAGG0yUT3FYqis/yKLfiUAA
Date: Wed, 11 Oct 2017 23:04:41 +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_94F62B6B74FE4EA796E781B649A60052ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [mpls] Spencer Dawkins' 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:04:51 -0000

Hi, Spencer,

Thanks for your review, please see inline.

On Oct 10, 2017, at 10:06 PM, Spencer Dawkins <<>> wrote:

Spencer Dawkins 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:


I can't emphasize strongly enough that my understanding of segment routing is
neophyte-level on a good day, but I do have a question about Section 8.

The question you are asking does not require exhaustive knowledge on segment routing. It does require knowledge of MPLS LSP Ping, and RFC 8029, though.

In fact, you should think of draft-ietf-mpls-spring-lsp-ping as another Section 3.2.x of RFC 8029.

With that in mind, see below.

I'm understanding that on a network path where some network elements support
segment routing while others do not, what you can measure is a ping or
traceroute to the first network element that doesn't support segment routing
(or is it to the last network element that does support segment routing?), but
you don't have any visibility along the path beyond that - do I have that right?

No. You still have visibility.

When there is mismatched capability in the nodes (meaning, SR-capable source, SR-unaware respondent, or viceversa), you still get a response but the TFS TLV validation might not be understood. Hence, you get visibility and nothing breaks if FEC changes.

The important bit is that this is in no way different from stitching LDP LSP and RSVP LSP.

A ping between SR-capable nodes over a set of non-SR nodes will not break the Ping. A trace can leverage “FEC Stack change” on the border node connecting SR and non-SR domain with relevant downstream FEC. In other words, SR-LDP Inter-Op is not different from other stitching scenarios. The only difference is with Adj-SID which is already mentioned in Section 8.

Assuming so …

Even when you cannot assume that and your initial statement is not right...

I didn't see anything about this topic before Section 8/page 16. Perhaps it's
worth mentioning whether this works earlier in the document, perhaps in the

… sure, we can add something.

My last point might not be in scope for this document, or even the SPRING
working group, but if this is a limitation, any suggestions you could make to
network operators with mixed networks (which I could imagine would be the rule,
rather than the exception, as the technology is deployed) about what they can
do to benefit most from this technology might be appreciated.

The idea is that transitional scenarios will be short-lived by definition (the motivation for deploying this is OpEx reduction, and a half-migration will achieve the oposite… the finances will drive a bit of an all-or-nothing attractor.

Still, we’ll add this as Section 1.1:

<section title="Coexistence of SR-Capable and Non-SR-Capable Node Scenarios">
<xref target="I-D.ietf-spring-segment-routing-ldp-interop" />
   describes how Segment
   Routing operates in a network where SR-capable and non-SR-capable
   nodes coexist. In such a network, one or more SR-based LSPs and
   non-SR-based LSPs are stitched together to achieve an end-to-end LSP.
   This is similar to network where LDP and RSVP nodes coexist and the
   mechanism defined in Section 4.5.2 of <xref target="RFC8029" /> is applicable for LSP
   Ping and Trace.
   Section 8 of this document explains one of the potential gap that is
   specific to SR-Capable and non-SR-capable node scenarios and explains
   how the existing mechanism defined in <xref target="RFC8029" /> handles it.


— Carlos.