Definition of Time to Live TLV for LSP-Ping Mechanisms
draft-ietf-mpls-lsp-ping-ttl-tlv-10

Version -10 has addressed my DISCUSS.  Thanks for that, and for also addressing my other comments.

I support Barry's DISCUSS point on section 3.2.

This document got on the agenda on August 4th, for the August 7th meeting. I got a complaint from the Secdir secretary that it is too short time for them to do their usual re-review for the telechat. He believes there is no issue in this document, but can we avoid this situation in the future?

Thanks, the concerns are addressed in the referenced RFC in the latest revision.

In section 3.1, do you want to put in the usual "Reserved - MUST be zero (MBZ) when sending and ignored on receipt."?

Barry's covered the rest.

It looks like my DISCUSS has been addressed.   The DISCUSS was:

I'm probably missing something here, so please help me out.   The text in 4.2 says:

   It is possible that the MPLS Echo Request packet was intercepted
   before the intended destination for reason other than label TTL
   expiry. This could be due network faults, misconfiguration or other
   reasons. In such cases, if the return TTL is set to the value
   specified in the TTL TLV then the echo response packet will continue
   beyond the originating node. This becomes a security issue.

   To prevent this, the label TTL value used in the MPLS Echo Reply
   packet MUST be modified by deducting the incoming label TTL on the
   received packet from TTL TLV value. If the MPLS Echo Request packet
   is punted to the CPU before the incoming label TTL is deducted, then
   another 1 MUST be deducted. In other words:

   Return TTL Value on the MPLS Echo Reply packet = (TTL TLV Value)-
   (Incoming Label TTL) + 1

The second paragraph concludes by saying "another 1 must be deducted," but the math in the third paragraph appears to be adding one, possibly because not enough parentheses were used.   What was intended here?