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

From: Spencer Dawkins <[email-masked]>
Date: Tue, 10 Oct 2017 19:06:30 -0700

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.

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?

Assuming so ...

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?

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.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 11 Oct 2017 23:04:41 +0000

Hi, Spencer,

Thanks for your review, please see inline.

On Oct 10, 2017, at 10:06 PM, Spencer Dawkins <[email-masked]<mailto:[email-masked]>> wrote:

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.

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...

… sure, we can add something.

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:

—>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.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 11 Oct 2017 18:30:46 -0500

Hi, Carlos,

On Wed, Oct 11, 2017 at 6:04 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> On Oct 10, 2017, at 10:06 PM, Spencer Dawkins <
> [email-masked]> wrote:
>
> 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.
>
> 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.
>

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

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

Thanks for walking me through this.

Spencer

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 11 Oct 2017 23:59:49 +0000

Hi Spencer,

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

—
Carlos Pignataro, [email-masked]<mailto:[email-masked]>

“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 <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Carlos,

On Wed, Oct 11, 2017 at 6:04 PM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Spencer,

Assuming so …

Spencer

—>8—

Thanks,

— Carlos.