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

[Antoni Przygienda <[e-mail]>]

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


<[e-mail]<mailto:[e-mail]>> spake:

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 <[e-mail]<mailto:[e-mail]>> wrote:
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” ;-) …


:-)

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


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.


Yes, that's the plan. Ack.


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

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


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


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

--- tony


<[e-mail]<mailto:[e-mail]>> spake:


·         “It may simplify