Subject: Re: [RTG-DIR] RtgDir review: https://www.ietf.org/id/draft-ietf-mpls-spring-lsp-ping-06.txt

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 2 Sep 2017 01:26:29 +0000

Hi, Tony,

Many thanks for taking the time to review this draft for RtgDir, and sorry for the delayed-ack.

You raise an important question, regarding the right-size scope of an atomic spec in modular protocol design, and the respective precision of its title. And that question seems to be the center of your major concern.

Do the "OSPF extensions for SR" cover all the currently talked about extensions? Is the title future proof? Can segment-routing-mpls be titled as such without ldp-interop bits or without mpls-anycast-segments? Can anything be published, ever, if waiting for having every other bit complete? The point is that the concern you raise is valid and an issue in general; it results in a set of trade offs; on scope of content, scope of title, or both.

In the case of this specific document, I do not disagree with your assessment that the tradeoff is exacerbated. At the same time, I disagree with some of your conclusions.

Please see inline for in-context follow-ups.

Sent from my iPad

On Aug 24, 2017, at 8:07 PM, Antoni Przygienda <[email-masked]<mailto:[email-masked]>> wrote:

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir<http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir>
Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.
Document: https://www.ietf.org/id/draft-ietf-mpls-spring-lsp-ping-06.txt
Reviewer: Tony Przygienda
Review Date: 08/17
Intended Status: Standards Track
Summary:

I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors. Overall, I think that both the quality as well as scope of the draft seems rushed to LC and at a deeper level, SR IMO maybe not in a state yet to deliver a complete, standards-track RFC for the scope the draft claims to cover unless its breadth gets heavily curtailed.

As note of caution: I’m not traditionally a MPLS/SR dataplane deep subject matter expert so I basically looked over the architectural integrity first and then read up enough detail to be fairly sure I make sense. Nevertheless, some of my comments may be off mark obviously.

Thanks for this heads up... :-)

Comments:

  *   The name of the draft implies a scope which it covers to a small degree only
  *   The draft feels somewhat rushed, contains numerous spelling mistakes, partial and mis-numbered references. It omits good amount of text that is necessary for a standards track spec in terms of being normative (missing capitalization, error conditions/mis-formatted input etc).
  *   I recommend to send the draft back to the WG until the according SIDs are mentioned/treated/stabilized to the point where it truly is a “SPRING LSP Ping” or otherwise rename the draft/RFC as “LSP Ping for IGP Prefix/adjacency SIDs” and address the comments pertaining to this scope

We talked about whether to wait for some SIDs (incl BGP) versus get a specification for what is needed today. Release early and often is the chosen path. This basically means get LSP Ping for prefix/adj SIDs now. Publish support for other SIDs as they are needed and become stable.

  *
Major Issues:

·         While claiming that it’s “LSP Ping/Trace for SPRING” the document does not mention many types of SIDs already defined today and/or does not differentiate enough between them

o    LAN adjacency SIDs (either that needs to be differentiated from adjacency SIDs or explained why it’s not necessary)

o    Binding SIDs

o    anycast SIDs

o    EPE SIDs

o    Mirroring SIDs?

o    possibly topology SIDs

o    in section 5.3 we have an assumption that GMPLS is running to support unnumbered links (4302)? How does that play with rfc3630 and incoming draft-ietf-ospf-lls-interface-id-00 identifiers.

o    we have Prefix Range in IGPs and the question is, should that be considered a special sub-type on LSP Ping Downstream mapping TLV?

o    How is the draft dealing with “controller installed SIDs”, how is that treated?

See above. The choice was to get support for Prefix and Adj SIDs.

·         Generally, I think it may be premature to publish the draft before the “SID types” have settled to a certain degree or otherwise it has to be renamed and address a much reduced scope.

I think this is a great suggestion. We should narrowscope within the title.

Also, broad ack to the minor issues and Nits.

Let us address all of these in a new revision, including all the minor, Nits, and title update.

Thanks!

Carlos.

Minor Issues:

·         “It may simplify implementations to reuse Implicit Null for Node Segment ID PHP and Adjacency Segment ID cases.”  What is this saying? This is not normative, does not explain how it can be done and whether a node encountering Implicit NULL for the SIDs does consider it an error, a correct “smart” implementation or anything else? Am I missing something?

·         Section 5.1 (and many other sections defining formats): No error condition treatements are specified anywhere. What happens if e.g. another value than 0,1,2 is received in the protocol field?
Nits:

·         Misspelled “supports hierarchal”

·         “is not hop-by-hop always” is awkward English ;-)

·         correction “the assignment can be unique to the node or within _a_ domain.”. We have multiple possible domains in SR (AD, area, mapping server tie-breaks)

·         “illustrates the problem and describe_s_ a mechanism”

·          “that is used to distribute a specific a label.” does not parse

·         “regardless of if PHP” would be better as e.g. “regardless whether”

·         “Adjacency Segment ID represents parallel adjacencies (Section 3.5.1 of [I-D.ietf-spring-segment-routing])”. In fact, section 3.5.1 deals with mapping server? 3.4.1 maybe?

·         “of &pop& operation” ?

·         “it can be thought _of_ as _a_ next hop destined _to a_ ? locally allocated segment that has PHP enabled.”

·         “When Protocol is OSPF, NP-flag defined in Section 5 of [I-D.ietf-ospf-segment-routing-extensions] should be set to 0.”. Probably MUST and in good couple of other places where normative language is not capitalized and an error on violation is implied by the section above.

---

From: Antoni Przygienda <[email-masked]>
Date: Sat, 2 Sep 2017 06:55:31 +0000

Hey Carlos, thanks for coming back. I was bit in arrears on the review myself but it’s the usual “these days, everyone has 900 pounds of rock to pile up every day” ;-) …

a)
“We talked about whether to wait for some SIDs (incl BGP) versus get a specification for what is needed today. Release early and often is the chosen path. This basically means get LSP Ping for prefix/adj SIDs now. Publish support for other SIDs as they are needed and become stable. “

Acknowledged. I understand SR is evolving, customers want practical subset of it quickly (but of course interoperable ;-) and some of the solid SIDs need earlier support than other, possibly more experimental stuff. All in sync here. So, if we’re really willing to talk about a title like ““LSP Ping for IGP Prefix and Adjacency SIDs” or similar then I think the scope is manageable and important and we should converge this draft in a expedient manner. And as you say, further drafts will cover further SIDs, modes of generating/provisioning/signaling SIDs.

In this context those points would be still major:

·         LAN adjacency SIDs (either that needs to be differentiated from adjacency SIDs or explained why it’s not necessary)

·         in section 5.3 we have an assumption that GMPLS is running to support unnumbered links (4302)? How does that play with rfc3630 and incoming draft-ietf-ospf-lls-interface-id-00 identifiers). The section on “unnumbered” links overall needs some tender loving care. We are having a bit of proliferation of bandaid-box patches on OSPF in this respect, some assuming MPLS signaling, some GMPLS and so on, all of them need consideration here IMO.

·         we have Prefix Range in IGPs and the question is, should that be considered a special sub-type on LSP Ping Downstream mapping TLVs?

·         And having thought a bit about it: do you disregard the mapping server interactions completely? One of the hard things is that mapping servers may not align boundaries, have collisions, tons flags on opaques and so on and figuring out WHY/WHO/BASED on WHAT mapped. Practically, maybe popping couple things into the signaling on LSP ping to know WHAT tie-broke and WHY in a little more detail could go a long way in terms of OAM for those SR SIDs.

b)       Rest were nits and clarifications need taken care of but are not worth repeating

c)       I suggest @ least one solid MPLS/SR data plane reviewer on this thing. LSP ping is a non-forward thing in my experience. Again, I’m not the best guy to do that.  One thing I struggle with architecturally on this LSP ping is always how the FEC change stuff is happening and whether all the nodes doing it have the necessary label info and the corner cases of that. I don’t see a way how this draft would get into trouble in this respect but it’s just something that merits review by someone who did the LSP ping stuff for a while IMO.
And Carlos, ultimately, I trust that my “tough love” here is interpreted the right way. SR is an important technology bunch of vendors implement(ed), bunch of customers heavily rely on interop and therefore drafts should be held to fairly high technical standard which is the only intention of the review I provide.

If we’re in sync, hit me with an improved/renamed version or otherwise let’s continue the discussion.

--- tony

<[email-masked]<mailto:[email-masked]>> spake:

·         “It may simplify

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 15 Sep 2017 14:34:59 +0000

Hi, Tony,

Thanks for the dialogue and sorry for the long round-trip. Please see inline.

On Sep 2, 2017, at 1:55 AM, Antoni Przygienda <[email-masked]<mailto:[email-masked]>> wrote:

:-)

Thank you for taking the time to do a thorough review, the goal is a quality specification.

a)

Yes, that's the plan. Ack.

We have some responses and a few document changes regarding all these points. Let us socialize and review with the full set of authors, post and get back.

Ditto.

That happens naturally this being an MPLS document (arguably that's the reason for MPLS hosting the doc. Part of the process there is MPLS-specific reviews.
And Carlos, ultimately, I trust that my “tough love” here is interpreted the right way. SR is an important technology bunch of vendors implement(ed), bunch of customers heavily rely on interop and therefore drafts should be held to fairly high technical standard which is the only intention of the review I provide.

Tony -- I much rather see a comprehensive thorough technical review (I think that's the other definition of "tough love") than going through the motions. The former improves the spec for everyone.

Being in four Directorates, I find myself often at both ends of the "tough love". If I wasn't clear: thank you!

Carlos.

--- tony

·         “It may simplify

---

From: Antoni Przygienda <[email-masked]>
Date: Fri, 15 Sep 2017 19:35:23 +0000

We’re cool and in-sync then. Excellent. I look forward to new-scope-tightened-up-and-improved version of this draft being critical piece of operationally successful SR long-term

thanks

--- tony

Hi, Tony,

:-)

a)

?         LAN adjacency SIDs (either that needs to be differentiated from adjacency SIDs or explained why it’s not necessary)

?         in section 5.3 we have an assumption that GMPLS is running to support unnumbered links (4302)? How does that play with rfc3630 and incoming draft-ietf-ospf-lls-interface-id-00 identifiers). The section on “unnumbered” links overall needs some tender loving care. We are having a bit of proliferation of bandaid-box patches on OSPF in this respect, some assuming MPLS signaling, some GMPLS and so on, all of them need consideration here IMO.

?         we have Prefix Range in IGPs and the question is, should that be considered a special sub-type on LSP Ping Downstream mapping TLVs?

?         And having thought a bit about it: do you disregard the mapping server interactions completely? One of the hard things is that mapping servers may not align boundaries, have collisions, tons flags on opaques and so on and figuring out WHY/WHO/BASED on WHAT mapped. Practically, maybe popping couple things into the signaling on LSP ping to know WHAT tie-broke and WHY in a little more detail could go a long way in terms of OAM for those SR SIDs.
We have some responses and a few document changes regarding all these points. Let us socialize and review with the full set of authors, post and get back.

Carlos.

--- tony

·         “It may simplify

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Fri, 22 Sep 2017 21:33:05 +0000

Hi Tony,

Much thanks for your review and tough love☺

I’ve started Last Call and if any additional comments, we can do as part of Last Call.

Much thanks for your cross-working group insight, especially bringing to our attention the ospf-lls draft which may not impact (yet) this draft but does appear to suggest impacts on RFC3630 and RFC4203 procedures. As it is now a working group draft, TEAS folks need to be aware of it.

Good weekend!
Deborah

From: Antoni Przygienda [mailto:[email-masked]]
Sent: Friday, September 15, 2017 3:35 PM
To: Carlos Pignataro (cpignata) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: RtgDir review: https://www.ietf.org/id/draft-ietf-mpls-spring-lsp-ping-06.txt

thanks

--- tony

Hi, Tony,

:-)

a)

Carlos.

--- tony

·         “It may simplify

---

From: Antoni Przygienda <[email-masked]>
Date: Sat, 23 Sep 2017 13:29:17 +0000

Deborah, thanks. My job ;-) On my plate to give the new version a read and come back with comments which can be taken as input further in the process

Thanks

--- tony

<[email-masked]<mailto:[email-masked]>> spake:

Hi Tony,

Good weekend!
Deborah

thanks

--- tony

Hi, Tony,

:-)

a)

Carlos.

--- tony

·         “It may simplify