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

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Wed, 11 October 2017 23:59 UTC

Return-Path: <cpignata@cisco.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FF1132939; Wed, 11 Oct 2017 16:59:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOA6UzVf2RHL; Wed, 11 Oct 2017 16:59:52 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2673A132025; Wed, 11 Oct 2017 16:59:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22324; q=dns/txt; s=iport; t=1507766392; x=1508975992; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TWj4Hn+jHhWzbMu3bOzQFTghu/aoRWRapIZ+xeGQbG0=; b=ZvKV48okTtY3/UzQfyU/gAlfmvmycxtWFNXtejvDMBCBAx6OGbzWz1El NJGiKt+oksV9rYJQdaQko/WOJUmqFqnpI3gUvw0E6y4bIPchFmWVMItRj R/kIkRJydIdFwzh+LuAIxuuLUFtxRkrmuDigGmAAyKN9B9V1CZxAxyx/+ k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CuAAD0r95Z/5ldJa1eGQEBAQEBAQEBAQEBBwEBAQEBgm8/LWRuJweDc4ofjy6BVIhniCuFPw6CBAojhRgCGoRFPxgBAgEBAQEBAQFrKIUeBiNWEAIBCD8DAgICHxEUEQIEDgWJQEwDFRCpfYInh0MNg2wBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYMtggeBUYIVC4I/NYJegXQBEgGDMi+CMgWKE5ZuPAKHXIgShHmCFIVziwiMe4g7AhEZAYE4AR84gQMLeBUfPAGETjkcGYFOdgGHCg0YB4EFgREBAQE
X-IronPort-AV: E=Sophos;i="5.43,363,1503360000"; d="scan'208,217";a="309703416"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Oct 2017 23:59:50 +0000
Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v9BNxomt025641 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Oct 2017 23:59:50 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 11 Oct 2017 19:59:49 -0400
Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1320.000; Wed, 11 Oct 2017 19:59:49 -0400
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
CC: The IESG <iesg@ietf.org>, "draft-ietf-mpls-spring-lsp-ping@ietf.org" <draft-ietf-mpls-spring-lsp-ping@ietf.org>, Loa Andersson <loa@pi.nu>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: Spencer Dawkins' No Objection on draft-ietf-mpls-spring-lsp-ping-11: (with COMMENT)
Thread-Index: AQHTQjWPQQPmtoAGG0yUT3FYqis/yKLfiUAAgAAHUACAAAgWgA==
Date: Wed, 11 Oct 2017 23:59:49 +0000
Message-ID: <65C8D6C6-050D-4351-A3D7-BEF34705B4FC@cisco.com>
References: <150768759039.24779.14955985625550079842.idtracker@ietfa.amsl.com> <94F62B6B-74FE-4EA7-96E7-81B649A60052@cisco.com> <CAKKJt-cr4Ra=xxY+Cpdrq=7cH88SkB=+=eY5GBh8m8WHU7fGgw@mail.gmail.com>
In-Reply-To: <CAKKJt-cr4Ra=xxY+Cpdrq=7cH88SkB=+=eY5GBh8m8WHU7fGgw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.116.133]
Content-Type: multipart/alternative; boundary="_000_65C8D6C6050D4351A3D7BEF34705B4FCciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/aKMDOSPDnHAyH8mcO4U7OW6I774>
Subject: Re: [mpls] Spencer Dawkins' No Objection on draft-ietf-mpls-spring-lsp-ping-11: (with COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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: Wed, 11 Oct 2017 23:59:54 -0000

Hi Spencer,

If this is helpful to you, it will likely help others. Happy this works, and you are welcome!

—
Carlos Pignataro, carlos@cisco.com<mailto:carlos@cisco.com>

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

On Oct 11, 2017, at 7:30 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com<mailto:spencerdawkins.ietf@gmail.com>> wrote:

Hi, Carlos,

On Wed, Oct 11, 2017 at 6:04 PM, Carlos Pignataro (cpignata) <cpignata@cisco.com<mailto:cpignata@cisco.com>> wrote:
Hi, Spencer,

Thanks for your review, please see inline.


On Oct 10, 2017, at 10:06 PM, Spencer Dawkins <spencerdawkins.ietf@gmail.com<mailto:spencerdawkins.ietf@gmail.com>> 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 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-spring-lsp-ping/



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

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.

This is exactly what I was missing.

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
Introduction?

… 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:

Only if this seems helpful to you, but it would have helped me :-)

Thanks for walking me through this.

Spencer

—>8—
<section title="Coexistence of SR-Capable and Non-SR-Capable Node Scenarios">
<t>
<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.
</t>
<t>
   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.
</t>
</section>
—>8—

Thanks,

— Carlos.