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

[Greg Mirsky <[e-mail]>]

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

Regards,
Greg

On Wed, Mar 1, 2017 at 2:21 PM, Benjamin Kaduk <[e-mail]> wrote:

> 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.
>
GIM>> Great catch, thank you. Indeed, Type is 8 bits-long. Corrected for
-15 version.

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

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

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
> repeating my as-yet unfulfilled intention to send further minor
> editorial patches to the authors.


> -Ben
>