Subject: [secdir] secdir re-review of draft-ietf-mpls-residence-time-14

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 1 Mar 2017 16:21:33 -0600

I previously reviewed the -12
(https://www.ietf.org/mail-archive/web/secdir/current/msg07110.html);
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
packets.

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

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.

-Ben

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 1 Mar 2017 21:39:55 -0800

Hi Ben,
sincerely appreciate your thorough review and the most helpful comments.
Please fine my answers in-line and tagged GIM>>.

Regards,
Greg

> intended to be the full 8 bits, given the assigned values in the
GIM>> Great catch, thank you. Indeed, Type is 8 bits-long. Corrected for
-15 version.

> all RTM-capable nodes, so signalling potential inclusion is odd.
GIM>> I think that I've missed 'not' in that sentence. So it should be
Presence of the RTM_SET TLV with I bit field set to 1
   indicates that some RTM nodes along the LSP could *not *be included in
the
   calculation of the residence time.
I've made the change in -15. Would you agree that it makes text logical?

> subsection,

GIM>> Would sub-section with title be acceptable?
RTM Capability Advertisement in Routing Protocols

> wondering whether the "Type" and "Length" fields in
> Figure 2 are the same octets of the packet as in Figure 1,

GIM>> Yes indeed. Figure 1 displays generic TLV while Figure 2 displays
particular TLV, PTP.

> and

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 2 Mar 2017 19:44:06 -0600

> I've made the change in -15. Would you agree that it makes text logical?

Yes, that seems much more logical.

> RTM Capability Advertisement in Routing Protocols

Yes, that sounds good.

> GIM>> Yes indeed. Figure 1 displays generic TLV while Figure 2 displays

Ah, good to have that confirmed.

> > editorial patches to the authors.

(I am about halfway through typing them up.)

-Ben

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 7 Mar 2017 09:34:25 -0800

Hi Ben, et.al,
many thanks for your the most thorough review, helpful comments and
patience. I've uploaded the new version of the draft that includes all
changes we've discussed and your editorial recommendations. Hope I haven't
missed any of them.

Regards,
Greg