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

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 01 Mar 2017 08:48:53 -0800

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?
- 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?
- Similar to Spencer's question: Why don't you also define a Sub-TLV
format for NTP?
- 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...?
- 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... 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); in turn
others are extended twice (e.g. PTP)...
- In figure 1, I would rename 'Value' to 'Sub-TLV' and maybe also
indicate it as optional in the figure: Sub-TLV (optional)

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 2 Mar 2017 18:47:18 -0800

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

Regards,
Greg

> https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/
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.

> value only)? Are you expecting to see more values here? What would those
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
GIM>>Hope that above answer addresses this question.

>   Maybe I don't understand what a bit-map field is here but these are
GIM>> '0b' identifies binary format as '0x' identifies hexadecimal format
of notation.

>   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
> - There are (still) some not spelled out abbreviations (LDP, PW);

GIM>> Since both are used only once - expanded

> in turn
GIM>>  Cleaned.

> indicate it as optional in the figure: Sub-TLV (optional)
GIM>> Agree

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 3 Mar 2017 10:46:06 +0100

Hi Greg,

see inline.

Mirja

> Am 03.03.2017 um 03:47 schrieb Greg Mirsky <[email-masked]>:
> 
> Hi Mirja,
> 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?

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

> GIM>>Hope that above answer addresses this question.

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

> GIM>> '0b' identifies binary format as '0x' identifies hexadecimal format of notation. 
Ah sorry, fully overview that.

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

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 3 Mar 2017 11:10:13 -0800

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) <[email-masked]
> wrote:

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

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

> > you just say that the rest as indicated by the length field must be
GIM2>> The description follows RFC 7794 Section 2.1

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

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 3 Mar 2017 20:19:02 +0100

Hi Greg,

two quick replies below.

Mirja

> Am 03.03.2017 um 20:10 schrieb Greg Mirsky <[email-masked]>:
> 
> 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) <[email-masked]> wrote:
> Hi Greg,
> 
> see inline.
> 
> Mirja
> 
> 
> 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.

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

> GIM2>> Thank you, I agree it is more logical flow. With the change suggested by Ben it will look like this:

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 6 Mar 2017 14:58:08 -0800

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) <
[email-masked]> wrote:

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

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 7 Mar 2017 14:26:03 +0100

Still not convinced because you can just use an new RTM TLV for this case.

On 06.03.2017 23:58, Greg Mirsky wrote:
> On Fri, Mar 3, 2017 at 11:19 AM, Mirja Kuehlewind (IETF) <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Greg,
>
>     two quick replies below.
>
>     Mirja
>
>     > Am 03.03.2017 um 20:10 schrieb Greg Mirsky <[email-masked]
>     <mailto:[email-masked]>>:
>     >
>     > Hi Mirja,
>     > On Fri, Mar 3, 2017 at 1:46 AM, Mirja Kuehlewind (IETF)
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     > Hi Greg,
>     >
>     > see inline.
>     >
>     > Mirja
>     >
>     >
>     > > Am 03.03.2017 um 03:47 schrieb Greg Mirsky <[email-masked]
>     <mailto:[email-masked]>>:
>     > >
>     > > Hi Mirja,
>     > > On Wed, Mar 1, 2017 at 8:48 AM, Mirja Kühlewind <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > > Please refer to
>     https://www.ietf.org/iesg/statement/discuss-criteria.html
>     <https://www.ietf.org/iesg/statement/discuss-criteria.html>
>     <https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/>
>     > >
>     > >
>     > >
>     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.
>
>     remember the identifier of the packet that you use to measurement
>     together with your measurement and wait for the next packet with the same
>     > > GIM>> Thank you for pointing. I'll update Figure 4 and Figure 5 to
>     add Value tag on the field immediately following RTM field.
>     >

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 7 Mar 2017 09:29:42 -0800

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 <[email-masked]> wrote:

>> [email-masked]
>>     > > GIM>> We may have another protocols or applications to use RTM
>> and these the most likely will have their specific set of parameters to
>>     > 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?
>>