Telechat Review of draft-ietf-mpls-residence-time-14

Request Review of draft-ietf-mpls-residence-time
Requested rev. no specific revision (document currently at 15)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2017-02-28
Requested 2017-01-31
Draft last updated 2017-03-01
Completed reviews Rtgdir Early review of -11 by He Jia (diff)
Genart Last Call review of -12 by Robert Sparks (diff)
Secdir Last Call review of -12 by Benjamin Kaduk (diff)
Opsdir Last Call review of -12 by Jürgen Schönwälder (diff)
Secdir Telechat review of -14 by Benjamin Kaduk (diff)
Genart Telechat review of -13 by Robert Sparks (diff)
Genart Telechat review of -14 by Robert Sparks (diff)
Assignment Reviewer Benjamin Kaduk
State Completed
Review review-ietf-mpls-residence-time-14-secdir-telechat-kaduk-2017-03-01
Reviewed rev. 14 (document currently at 15)
Review result Has Nits
Review completed: 2017-03-01


I previously reviewed the -12
the -14 seems much improved.  On this re-read, I have a better sense
of how the various TLVs and sub-TLVs fit together to achieve the
goal of having the RTM-capable nodes identify each other and
collaborate to account for residence time when processing timing

I have no security concerns with the document, as the updated
security considerations address the concerns previously raised.

However, there are a couple of issues that should probably block
publication (but ought to be easy to resolve):

Figure 7 appears to only be 31 bits wide, not 32 -- 'Type' is 7
bits, 'Length' 8, 'I' 1, and 'Reserved' 15.  Presumably Type is
intended to be the full 8 bits, given the assigned values in the

On page 16, second paragraph:

   The ingress node MAY inspect the I bit flag received in each RTM_SET
   TLV contained in the LSP_ATTRIBUTES object of a received Resv
   message.  Presence of the RTM_SET TLV with I bit field set to 1
   indicates that some RTM nodes along the LSP could be included in the
   calculation of the residence time.  An ingress node MAY choose to
   resignal the LSP to include all RTM nodes or simply notify the user
   via a management interface.

Is that supposed to be "included" or "excluded"?  My reading of the
previous paragraph was that the I bit would be set when a node
failed to compute the next RTM-capable node along the path, and of
course, we expect normal operation to include the residence time for
all RTM-capable nodes, so signalling potential inclusion is odd.

I'll close off this review by noting that sections 4.3 through 4.6
seem to all talk about how to use other protocols to indicate that
RTM may be used and could perhaps be grouped into an intermediate
subsection, wondering whether the "Type" and "Length" fields in
Figure 2 are the same octets of the packet as in Figure 1, and
repeating my as-yet unfulfilled intention to send further minor
editorial patches to the authors.