Subject: RFC 4379 errata

From: Alfred Hönes <[email-masked]>
Date: Sat, 12 Aug 2006 18:39:45 +0200 (MESZ)

Hello,
reading the recently published RFC 4379 (Detecting MPLS Data Plane
Failures) authored by you, I found a couple of textual issues that
perhaps should be addressed by an RFC Errata Note.

I use change bars ('|' in column 1) to mark issues/changes.
Proposed (changed) text is re-adjusted to conform with RFC
formatting rules.

(1)  Section 3 -- Wrong Length value in example

The FEC TLV example on page 9 starts with the lines:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type = 1 (FEC TLV)       |          Length = 12          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      [...]
      [ followed by 8 words (of 4 bytes each) ]

According to Section 3.3 of the LDP specification, RFC 3036,
the Lenght element of LDP TLVs measures the size of the Value
element in bytes.
Therefore, 'Length = 12' is wrong, it should be 'Length = 32'.

Hence, the RFC should say:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     |      Type = 1 (FEC TLV)       |          Length = 32          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      [...]

(2)  Section 3.3.1 -- formating error

The second encoding diagram on page 27,

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0
   0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0| +-+-+-
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1
   0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1
   0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1 0 1
   0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-+-+-
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1 0 1 0 1
   0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-+-+-
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

should say:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(3)  Section 4.4 -- word omission

On page 35, the RFC text contains the bullet:

   Best-return-code:  contains the return code for the echo reply packet
                      as currently best known.  As algorithm progresses,
                      this code may change depending on the results of
                      further checks that it performs.

It should say:

   Best-return-code:  contains the return code for the echo reply packet
|                     as currently best known.  As the algorithm
                      progresses, this code may change depending on the
                      results of further checks that it performs.

(4)  Section 4.4 -- word omission in pseudo-code comment

On page 38, within the pseudocode comment, the RFC says:

         [...]
         may be greater than Label-stack-depth.  To be consistent with
         the above stack-depths, the bottom is considered to entry 1.
         */

It should say:

         [...]
         may be greater than Label-stack-depth.  To be consistent with
|        the above stack-depths, the bottom is considered to be entry 1.
         */

(5)  Section 4.4 -- wrong internal section reference

The last paragraph of section 4.4 (Step 7.), on page 40, says:

      Send an MPLS echo reply with a Return Code of Best-return-code,
      and a Return Subcode of Best-rtn-subcode.  Include any TLVs
      created during the above process.  The procedures for sending
|     the echo reply are found in subsection 4.4.1.
                                             ^^^^^
It should say:

      Send an MPLS echo reply with a Return Code of Best-return-code,
      and a Return Subcode of Best-rtn-subcode.  Include any TLVs
      created during the above process.  The procedures for sending
|     the echo reply are found in subsection 4.5.

(6)  Section 5.1 -- outdated Normative Reference

On page 43, the tag  [NTP]  points to RFC 2030.
At the time of publication of RFC 4377, RFC 2030 already had been
obsoleted by RFC 4330.
Therefore, the text after  [NTP]  should be replaced by the
rfc-ref.txt entry for RFC 4330.

(7)  Section 6 -- typo

At the end of the second paragraph on page 4, the RFC says:

                                    [...].  However, to provide a
   stronger defense, an implementation MAY also validate the TimeStamp
|  Sent by requiring and exact match on this field.
                       ^

It should say:

                                    [...].  However, to provide a
   stronger defense, an implementation MAY also validate the TimeStamp
|  Sent by requiring an exact match on this field.

Authors, please comment, or just acknowledge to the RFC Editor
the above material for publication in an RFC Errata Note.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+