Re: [mpls] Mirja Kühlewind's No Objection on draft-ietf-mpls-residence-time-14: (with COMMENT)

[Greg Mirsky <[e-mail]>]

Hi Mirja,
thank your for the review and the comments, most helpful.
Please find my answers in-line tagged GIM>>.

Regards,
Greg

On Wed, Mar 1, 2017 at 8:48 AM, Mirja Kühlewind <[e-mail]> wrote:

> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-mpls-residence-time-14: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> High level comment:
> Maybe extend the security section a bit and describe what can happen in
> the worse case if the value has been modified to a too high or too low
> value; and maybe even given some guidance on performing additional checks
> to figure out if a given value is reasonable for a given path or not.
>
> Questions:
> - Can you explain why PTPType, Port ID, and Sequence ID are needed in the
> PTP Sub-TLV format if those values are already in the PTP packet itself
> that follows?
>
GIM>> We propose to copy these values as they uniquely identify PTP control
message as these are required for two-step mode and suggesting inspection
of the PTP payload would cause layer violation.

- Why is it necessary to define PTP sub-TLV (and have a registry for one
> value only)? Are you expecting to see more values here? What would those
> values be?
>
GIM>> We may have another protocols or applications to use RTM and these
the most likely will have their specific set of parameters to uniquely
identify control session for two-step mode. One obvious case would be NTP
when on-path support is defined. But since we don't know which parameters
will uniquely identify cotrol session we don't request code point
allocation.

> - Similar to Spencer's question: Why don't you also define a Sub-TLV
> format for NTP?
>
GIM>>Hope that above answer addresses this question.

> - sec 4.3: "RTM (capability) - is a three-bit long bit-map field with
> values
>       defined as follows:
>       *  0b001..."
>   Maybe I don't understand what a bit-map field is here but these are
> more then 3 bits...?
>
GIM>> '0b' identifies binary format as '0x' identifies hexadecimal format
of notation.

> - also sec 4.3.: "Value contains variable number of bit-map fields so
> that overall
>       number of bits in the fields equals Length * 8."
>   However there is no field 'Value' in the figure...

GIM>> Thank you for pointing. I'll update Figure 4 and Figure 5 to add
Value tag on the field immediately following RTM field.

> Also the following
> explanation about future bit-maps is really confusing to me; why don't
> you just say that the rest as indicated by the length field must be
> padded with zeros...?
> - Should section 4.8 maybe be a subsection of 4.7? This part confused me
> a bit because the example seems to be generic but the rest is RSVP-TE
> specific, right? Maybe move the example as a separate section before or
> after the whole section 4...?
>
> Nits:
> - Maybe change to title to: Residence Time Measurement (RTM) in MPLS
> network
> - There are (still) some not spelled out abbreviations (LDP, PW);

GIM>> Since both are used only once - expanded

> in turn
> others are extended twice (e.g. PTP)...
>
GIM>>  Cleaned.

> - In figure 1, I would rename 'Value' to 'Sub-TLV' and maybe also
> indicate it as optional in the figure: Sub-TLV (optional)
>
GIM>> Agree