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

[Greg Mirsky <[e-mail]>]

Hi Mirja, et. al,
I've uploaded the update to the draft. We've done our best to address your
many comments.

Kind regards,
Greg

On Tue, Mar 7, 2017 at 5:26 AM, Mirja Kühlewind <[e-mail]> wrote:

> Still not convinced because you can just use an new RTM TLV for this case.
>
> On 06.03.2017 23:58, Greg Mirsky wrote:
>
>> Hi Mirja,
>> we use sub-TLV in Figure 2 as future proofing approach in case someone may
>> need to define different sub-TLV that MUST precede the PTP packet.
>> Would you agree that it is reasonable design choice?
>>
>> Regards,
>> Greg
>>
>> On Fri, Mar 3, 2017 at 11:19 AM, Mirja Kuehlewind (IETF) <
>> [e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>     Hi Greg,
>>
>>     two quick replies below.
>>
>>     Mirja
>>
>>     > Am 03.03.2017 um 20:10 schrieb Greg Mirsky <[e-mail]
>>     <mailto:[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] <mailto:[e-mail]>> wrote:
>>     > Hi Greg,
>>     >
>>     > see inline.
>>     >
>>     > Mirja
>>     >
>>     >
>>     > > Am 03.03.2017 um 03:47 schrieb Greg Mirsky <[e-mail]
>>     <mailto:[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]
>>     <mailto:[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
>>     <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/
>>     <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
>>     > >
>>     >
>>     >
>>
>>
>>