Skip to main content

Last Call Review of draft-ietf-mpls-spring-lsp-ping-06
review-ietf-mpls-spring-lsp-ping-06-rtgdir-lc-vainshtein-2017-09-20-00

Request Review of draft-ietf-mpls-spring-lsp-ping
Requested revision No specific revision (document currently at 13)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2017-09-20
Requested 2017-09-06
Requested by Deborah Brungard
Authors Nagendra Kumar Nainar , Carlos Pignataro , George Swallow , Nobo Akiya , Sriganesh Kini , Mach Chen
Draft last updated 2017-09-20
Completed reviews Rtgdir Early review of -06 by Tony Przygienda (diff)
Rtgdir Last Call review of -06 by Sasha Vainshtein (diff)
Secdir Last Call review of -11 by Stephen Farrell (diff)
Genart Last Call review of -11 by Wassim Haddad (diff)
Comments
Tony P did an early review - select someone else for this prep for Last Call review.
Assignment Reviewer Sasha Vainshtein
State Completed
Review review-ietf-mpls-spring-lsp-ping-06-rtgdir-lc-vainshtein-2017-09-20
Reviewed revision 06 (document currently at 13)
Result Has Issues
Completed 2017-09-20
review-ietf-mpls-spring-lsp-ping-06-rtgdir-lc-vainshtein-2017-09-20-00
Hi,
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

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: Alexander (“Sasha”) Vainshtein

Review date: 20.09.2017

IETF LC End Date: Not known

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.

Comments:

I have noticed that there is an earlier review of the same version of  the
draft<https://www.ietf.org/mail-archive/web/rtg-dir/current/msg03542.html>, and
I fully agree with the previous reviewer regarding the overall impression and
specific issues raised. I have tried to avoid reporting the same issues again
and focus only on new issues.

This review have been done on a very tight schedule for me, and therefore I
could have missed some issues and definitely many nits. The tight schedule has
also limited my ability to discuss the draft with the authors in sufficient
detail – but some interactions did took place. I would like to thank the
authors for their cooperation.

Major Issues:

1.       Section 7.4 “Segment ID Check” of the draft claims to update “the
procedure defined in Step 6 of Section 4.4  of [RFC8029]”. However, I have
failed to integrate the logic defined by the pseudocode in this section with
the logic defined by the referenced pseudocode.

a.       I have suspected that the newly introduced logic should be part of the
Egress FEC Validation logic defined in Section 4.4.1 of RFC 8029.  This
suspicion has been acknowledged by the authors, and they plan to fix the wrong
reference in the next revision of the draft.

b.       From my POV the best way to avoid possible misinterpretation by the
implementers would be inclusion of the updated version of the pseudocode (with
explicit marking of the new logic) directly in the document. I have suggested
this to the authors, but I did not get their response so far.

2.       I agree with the previous reviewer regarding the mismatch between the
(presumed) claim and the actual scope covered by the draft. To the best of my
understanding, the authors have already agreed to fix this in the next revision
of the draft. Minor Issues:

1.       I wonder why the authors place such an emphasis on Service labels
(which, AFAIK, have not been defined in any level of detail anywhere so far) –
these labels are mentioned in Sections 4.2, 5 (that mentions them as “Service
segments”)  and 8, while so many types of Segment IDs that are already well
defined both in the SRPING WG documents and in the extensions of the relevant
routing protocols are left out of scope of the draft.  The authors have
acknowledged this and plan to fix this issue (probably by removing the Service
labels completely).

2.       The description of possible data plane malfunctions in section 4.1
seems to assume that all the nodes in the referenced topology (shown in Figure
1) us the same SRGB. If this assumption (which is not explicitly mentioned) is
not correct, the LSP Ping Echo request packets would not be “delivered to their
expected destinations but not via the expected path” (as the text in this
section claims). I suggest making any such assumptions explicit in the text

3.        I am not sure if “OSPF” and ISIS” (without any reference to Segment
Routing) are the proper names for the label distribution protocols in the
proposed new IANA registry in Section 10.2. From my POV “OSPF/ISIS SR
Extensions” would be more appropriate. The authors disagree with this proposal
claiming that OSPF and ISIS are not used for label distribution in any other
way. (RFC 8029 that encodes the label distribution protocol in the Downstream 
Detailed Mapping TLV did not request a dedicated registry for this purpose, and
I think that the authors have been right to request such a registry).

4.       I doubt the draft needs address any FRR issues even in future (as
mentioned in the last statement in Section 5), since, to the best of my
understanding, any form of FRR:

a.       Is operated locally by the node that is upstream to the failure
without passing any information to the initiator of LSP-Ping Request packets

b.       In any case is just a transient state in the (presumably short)
interval between the failure being detected by the upstream node and
re-convergence of IGP I also think that references to “future versions” are not
quite appropriate in the document that is going to the IETF LC. I recommend
removing any such references from the document,

5.       Section 9 “Backward Compatibility with non-Segment Routing devices”
defines the behavior for the two slightly different use cases:

a.       LSP Ping Echo Request packets are initiated by an SR-capable node (and
therefore their target FEC stack contains SR-related FECs), while the responder
is legacy device that is not SR-capable. In this case the proposed solution
(respond with the FEC-return-code “Replying router has no mapping for the FEC
at stack-depth”) looks as the only possibility since the legacy device cannot
parse SR FECs in any case

b.       LSP Ping Echo Request packets are initiated by a legacy device while
the responder is SR-capable. The draft defines the same behavior in this case –
but, IMHO and FWIW, the responder could provide slightly better diagnostics
since it can parse the “old” target FEC and recognize the equivalent Node ID.
An additional return code would be required to implement this behavior. This
issue has not been discussed with the authors due to lack of time. Nits:

1.       The note to the RFC Editor in Section 10 mentions early IANA
allocation for some Sub-TLV types defined in the document – but, as of today,
these early allocations have already expired (they have been in force until
15.09.17).  I have to admit that I do not fully understand the implications of
this fact – e.g., whether the authors may continue to refer to the specific
values of parameters (e.g., Sub-TLV 34, 35 etc.) for which early IANA
allocation has expired, or should use some other form of reference (e.g., TBDx).

2.       The draft mentions a TBD7 value to be assigned by IANA, but there are
no TBD1, …, TBD6. The authors have acknowledged this and plan to fix it.
However, I do not know how this can be affected by expiration of early IANA
allocations (see above)

3.       I have failed to understand the intention of the authors regarding
already mentioned Service labels from the following statement in section 8:
“How a node treats Service label is outside the scope of this document and will
be included in this or a different document later”. Of course, if the Service
labels are removed from the draft, this sentence would hopefully disappear with
its internal controversy.

Regards,
Sasha

Office: +972-3926302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information
which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have
received this transmission in error, please inform us by e-mail, phone or fax,
and then delete the original and all copies thereof.
___________________________________________________________________________