Subject: RFC 4872 issues and errata

From: Alfred Hönes <[email-masked]>
Date: Mon, 7 May 2007 21:30:04 +0200 (MESZ)

Hello,
after studying the recently published RFC 4872 (GMPLS E2E Recovery)
authored by you, I would like to submit a few comments, pointing
out some issues I found with the RFC text, and supplying material
for an appropriate RFC Errata Note.

The items below are presented in RFC textual order.
I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
Modified text has been re-adjusted to match RFC formatting
rules, where appropriate.

(1)  Section 14.1

Within the explanations for the PROTECTION Object, on mid-page 32
RFC 4872 says:

|     Reserved: 5 bits
                ^
It should say:

|     Reserved: 6 bits
                ^
Rationale:
  See the artwork of the object on page 31 and count the bits!

(2)  Section 15.1

(2a)
The first paragraph of Section 34, on top of page 34, says:

   The primary path route is specified via the PRIMARY_PATH_ROUTE object
   (PPRO).  The Primary Path Route Class Number (Class-Num) of form
|  0bbbbbbb 38.
           ^
It should say:

   The primary path route is specified via the PRIMARY_PATH_ROUTE object
   (PPRO).  The Primary Path Route Class Number (Class-Num) of form
|  0bbbbbbb is 38.
           ^^^^
or even:

   The primary path route is specified via the PRIMARY_PATH_ROUTE object
   (PPRO).  The Primary Path Route Class Number (Class-Num) of form
|  0bbbbbbb assigned by IANA is 38.
           ^^^^^^^^^^^^^^^^^^^^^

Rationale: grammar.

(2b)
The second-to-last paragraph of Section 34, just below the artwork
on page 34, says:

   The contents of a PRIMARY_PATH_ROUTE object are a series of
|  variable-length data items called subobjects (see Section 15.3).
                                                                ^
It should say:

   The contents of a PRIMARY_PATH_ROUTE object are a series of
|  variable-length data items called subobjects (see Section 15.2).
                                                                ^
Rationale: See headline and content of Section 15.2 !

(3)  Section 15.2

Within Section 15.2, the first paragraph on page 35 says:

|  An empty PPRO with no subobjects is considered illegal.  If there is
|  no first subobject, the corresponding Path message is also in error,
   and the receiving node SHOULD return a PathErr message with the new
   error code/sub-code "Routing Problem/Bad PRIMARY_PATH_ROUTE object".

According to the text, PPROs are only admitted in Path messages.
PPROs "with no first subobject" carry no subobjects at all.
It is unclear why the text tries to distinguish these 'too cases'
and uses the word, "also", in the second sentence.

Something significant might have been lost in the text,
which cannot be concluded from the context.
In this case, please supply the missing clues.
Otherwise, the RFC should say unambiguously:

|  An empty PPRO with no subobjects is considered illegal.  A node
|  receiving an empty PPRO SHOULD return a PathErr message with the new
   error code/sub-code "Routing Problem/Bad PRIMARY_PATH_ROUTE object".

(4)  Section 16

The second paragraph of Section 16 is a literal restatement of the
first sentence of the same section, on the same page (37).
Therefore, the last text line of Section 16,

   The ASSOCIATION object is used to associate LSPs with each other.

should be deleted.

(5)  Section 16.2

The last paragraph of Section 16.2, on page 39, says (including the
spurious blank line):

|   [...]  Similarly, terminating nodes receiving a Path message with a
|
|  PROTECTION object requiring association between working and recovery
|  LSPs MUST include an ASSOCIATION object.  Otherwise, such nodes MUST
   return a PathErr message with the new error code/sub-code "Routing
   Problem/PROTECTION object not Applicable".

The first sentence quoted IMHO does not make sense: The *receiver*
of a Path message cannot include anything into that message.
I strongly suspect that this text is garbled and should in fact state
precisely:

|   [...]  Similarly, a Path message with a PROTECTION object requiring
|  association between working and recovery LSPs MUST include an
|  ASSOCIATION object.  Terminating nodes receiving such Path message
|  without an ASSOCIATION object MUST return a PathErr message with the
   new error code/sub-code "Routing Problem/PROTECTION object not
   Applicable".

(6)  Section 17

The first paragraph of Section 17 does not confine the scope of the
specification as it would be appropriate.

The text says:

|  This section presents the RSVP message-related formats as modified by
|  this document.  Unmodified RSVP message formats are not listed.

It should say:
                                 vvv
|  This section presents the RSVP-TE message-related formats as modified
|  by this document.  Unmodified RSVP-TE message formats are not listed.
                                     ^^^
Rationale:
  'Classic' RSVP (RFC 2205) is neither covered nor affected by the
  subsequently specified message formats.

(7)  Section 18

The 4th paragraph of Section 18 (on page 40) says:

   [...]                                       v
|  In the case, when the same level of security provided by [RFC2747] is
   desired, the standard IPsec based integrity and authentication can be
   used as explained in [RFC3473].

It should say:

   [...]                                       vvvv
|  In the case, when the same level of security as provided by [RFC2747]
   is desired, the standard IPsec based integrity and authentication can
   be used as explained in [RFC3473].

Please comment.

IMHO, all items above seem to be appropriate for an Errata Note.

Preferrably, you should submit an Author's Errata Note to the
RFC Editor's RFC Errata web pages, making freely use of the
material supplied above.  But if you like, I can formally
submit an Errata Note on my own, with your consent.

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