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

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

Hi Greg,

two quick replies below.

Mirja

> Am 03.03.2017 um 20:10 schrieb Greg Mirsky <[e-mail]>:
> 
> Hi Mirja,
> thank you for your comments and very helpful discussion. My notes in-lined and now tagged with GIM2>>
> 
> Regards,
> Greg
> 
> On Fri, Mar 3, 2017 at 1:46 AM, Mirja Kuehlewind (IETF) <[e-mail]> wrote:
> 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?
> GIM2>> Will the following, when added at the very end of Section 3.1, work:
>    Tuple of PTPType, Port ID, and Sequence ID uniquely identifies PTP
>    control packet encapsulated in RTM message and are used in two-step
>    RTM mode Section 2.1.1.
> 
> GIM2>> The RTM message created by egress or the first on the LSP two-step RTM node. Thus other RTM nodes don't need to look into PTP control message but use the PTP sub-TLV. Creating new identifier is certainly an alternative but I believe that will require more state coordination between LERs on the same RTM LSP. Re-using existing characteristic information, in my view, is simpler solution.

Yes the new text helps. I don’t see why there is any more coordination needed if you use an identifier. If you are in two-step mode, you simply remember the identifier of the packet that you use to measurement together with your measurement and wait for the next packet with the same identifier. I don’t think that’s any different than using the PTP information as identifier. Anyway that’s not an big issue.

> 
> >
> > - 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.
> GIM2>> RTM TLV differentiates  between different encapsulation types, e.g. Ethernet, IPv4 or IPv6 but sub-TLV doesn't have to. Do you see this as a problem?

I still don’t fully understand this. You can use the same sub-TLV even if that sub-TLV is not extensible. All I’m saying is that I don’t understand why the sub-TLV in figure 2 has again a type and a value. I don’t think those two field are needed.

> 
> > - 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...?
> GIM2>> The description follows RFC 7794 Section 2.1 
> > - 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...?
> GIM2>> Thank you, I agree it is more logical flow. With the change suggested by Ben it will look like this:
>    4.  Control Plane Theory of Operation . . . . . . . . . . . . . .  10
>      4.1.  RTM Capability  . . . . . . . . . . . . . . . . . . . . .  10
>      4.2.  RTM Capability Sub-TLV  . . . . . . . . . . . . . . . . .  11
>      4.3.  RTM Capability Advertisement in Routing Protocols . . . .  11
>        4.3.1.  RTM Capability Advertisement in OSPFv2  . . . . . . .  11
>        4.3.2.  RTM Capability Advertisement in OSPFv3  . . . . . . .  13
>        4.3.3.  RTM Capability Advertisement in IS-IS . . . . . . . .  13
>        4.3.4.  RTM Capability Advertisement in BGP-LS  . . . . . . .  13
>      4.4.  RSVP-TE Control Plane Operation to Support RTM  . . . . .  14
>        4.4.1.  RTM_SET TLV . . . . . . . . . . . . . . . . . . . . .  15
> 
> >
> > 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
> >
> 
>