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

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi Greg,

see inline.

Mirja


> Am 03.03.2017 um 03:47 schrieb 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.

I see. Maybe add a sentence that these field are use to identify the packet. However, when you copy them, you also have to inspect the payload and that’s the same layer violation. Also not sure if duplicating information in the packet is the best approach. Why don’t use just add an own identifier to the packet instead?

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

My understanding was that a new protocol would be a different RTM TLV in the registry in section 7.2. That’s fine. I don’t understand why your PTP sub-TLV needs ANOTHER TLV scheme: figure 2 and registry in sec 7.3.

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

Actually not really. Why don’t you know which parameters to use?

> - 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. 
Ah sorry, fully overview that.

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

There are more questions here:

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