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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Carlos,

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

> Hi, Spencer,
>
> Thanks for your review, please see inline.
>
>
> On Oct 10, 2017, at 10:06 PM, Spencer Dawkins <
> [e-mail]> 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.
>
>
>
>
>