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

[Greg Mirsky <[e-mail]>]

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



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