Subject: RFC 4873 issues and errata

From: Alfred Hönes <[email-masked]>
Date: Tue, 8 May 2007 22:31:39 +0200 (MESZ)

Hello,
after studying the recently published RFC 4873 (GMPLS Segment
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 2

Near the end of the second-to-last paragraph on page 5, RFC 4873 says:

                                                        [...].  The
   branch node of a recovery LSP creates an SRRO by copying the RRO from
|  the Resv message of associated recovery LSP into a new SRRO object.
   Any SRROs present in the recovery LSP's Resv message are also copied.

It should say:
                                                        [...].  The
   branch node of a recovery LSP creates an SRRO by copying the RRO from
|  the Resv message of the associated recovery LSP into a new SRRO
   object.  Any SRROs present in the recovery LSP's Resv message are
   also copied.

Rationale:  missing article.

(2)  Section 3.2

On page 7, the last sentence of Section 3.2 says:

|              [...].  This object MUST NOT be used when association is
   made according to the methods defined in [RFC4090].

It should say:

|              [...].  This object MUST NOT be used when an association
   is made according to the methods defined in [RFC4090].

Rationale:  missing article.

(3)  Section 4.1

On page 8, Section 4.1 says:

                   [...].  This includes the definition of subobjects
|  defined for EXPLICIT_ROUTE object.  The class of the
   SECONDARY_EXPLICIT_ROUTE object is 200 (of the form 11bbbbbb).

It should say:

                   [...].  This includes the definition of subobjects
|  defined for the EXPLICIT_ROUTE object.  The class of the
   SECONDARY_EXPLICIT_ROUTE object is 200 (of the form 11bbbbbb).

Rationale:  missing article.

(4)  Section 4.2

In the second paragraph on page 10, Section 4.2 says:

|  At a branch node, the SERO, together with the Path message of LSP
   being recovered, provides the information to create the recovery LSP.
   [...]

It should say:

|  At a branch node, the SERO, together with the Path message of the LSP
   being recovered, provides the information to create the recovery LSP.
   [...]

Rationale:  missing article.

(5)  Section 4.2.1

Near the bottom of page 10, the first paragraph of Section 4.2.1 says:

                                                          [...].  The
|  processing of these events depend on a number of factors.

It should say:
                                                          [...].  The
|  processing of these events depends on a number of factors.
                                    ^
Rationale:  grammar.

(6)  Section 4.2.3

The first sentence in Section 4.2.3 (on page 12),

|  In general, objects in a recovery LSP are created based on the
|  corresponding objects in the LSP being protected.  [...]

IMHO makes use of too sluggish language; talking about
"objects in a recovery LSP" or "objects in the LSP being protected"
should be avoided because it messes up the essentials of [G]MPLS,
the separation of the data plane carrying arbitrary labeled data
packets and the control plane (with RSVP-TE carrying the TE objects).
Unfortunately, similar language recurs at other places in the RFC;
for the sake of brevity, I refrain from listing all those instances
below.

I would appreciate very much future derived and/or related work to
return to a more precise language.

(7)  Section 4.2.4

Still on page 12, Section 4.2.4 says:

   Recovery LSP removal follows standard procedures defined in [RFC3209]
|  and [RFC3473].  This includes with and without setting the
|  administrative status.

It remains unclear whether there has been some text inadvertently
lost in the second sentence, or if that is another instance of
rather sluggish language, which should be avoided according to all
published RFC authoring guidelines.

(8)   Section 4.3.1

(8a)
The third paragraph of Section 4.3.1 (on page 13) says:

|  Branch and merge nodes SHOULD also add a NOTIFY_REQUEST object to the
   LSP being protected.

This is another outstanding instance of the issue mentioned in
item (6) above.

(8b)
The final bullet on page 14 says:

   o new text:
      If a message contains multiple NOTIFY_REQUEST objects, only the
|     first object used is in notification.  Subsequent NOTIFY_REQUEST
      objects MUST be propagated in the order received.

Again, it is unclear whether text has been lost, or "the ... object
used is in notification" is another instance of very sluggish and
inprecise language.

Perhaps, the text was intended to say:

   o new text:
      If a message contains multiple NOTIFY_REQUEST objects, only the
|     first object is used to potentially trigger a notification.
      Subsequent NOTIFY_REQUEST objects MUST be propagated in the order
      received.

(9)  Section 4.3.2

The second sentence of Section 4.3.2 says:

|                      [...].  When a branch or merge node receives
   notification of an LSP failure and it is unable to recover from that
   failure, [...]

It should say:
|                      [...].  When a branch or merge node receives a
   notification of an LSP failure and it is unable to recover from that
   failure, [...]

Rationale:  missing article.

(10)  Section 5.1

The first paragraphh of Section 5.1 says:

   The format of a SECONDARY_RECORD_ROUTE object is the same as a
   RECORD_ROUTE object, Class number 21.  This includes the definition
   of subobjects defined for RECORD_ROUTE object.  The class of the
   SECONDARY_RECORD_ROUTE object is 201 (of the form 11bbbbbb).

It should say:

|  The format of a SECONDARY_RECORD_ROUTE object is the same as for a
   RECORD_ROUTE object, Class number 21.  This includes the definition
   of subobjects defined for the RECORD_ROUTE object.  The class of the
   SECONDARY_RECORD_ROUTE object is 201 (of the form 11bbbbbb).

Rationale:
a) improper comparison:  *format* of an object <--> another object;
b) missing article.

(11)  Section 6.1

The first paragraph of Section 6.1, on page 16, says:

   LSP Segment Recovery Flags are carried in the PROTECTION object of
|  the same C-Type defined in [RFC4872].  The format of the flags are:

It should say, e.g.:

   LSP Segment Recovery Flags are carried in the PROTECTION object of
|  C-Type 2 defined in [RFC4872].  The format of the modifed PROTECTION
|  object carrying these flags is:

Rationale:
a) language
b) The second sentencs is wrong.  The subsequent diagram depicts
   *the full object*, not only the (new) *flags* (in the third word
   of the object) !  The proposed word "modified" could also be
   replaced by "updated" or "amended".

(12)  Section 6.2

(12a)
The last sentence of the third paragraph of Setcion 6.2,
on mid-page 17, says:

                                                             [...].  The
   dynamically identified information, together with the Path message of
|  LSP being recovered, is used to create the recovery LSP.

It should say:
                                                             [...].  The
   dynamically identified information, together with the Path message of
|  the LSP being recovered, is used to create the recovery LSP.

Rationale:  missing article.

(12b)

The rules given in the two paragraphs on top of page 18,

   The resulting Path message is used to create the recovery LSP.  While
   the recovery LSP exists, the PROTECTION object in the original Path
   message  (unless overridden by local policy) MUST also be updated
   with the In-Place bit set (1).  From this point on, Standard Path
   message processing is used in processing the resulting and original
   Path messages.

   The merge node of a dynamically controlled recovery LSP SHOULD reset
   (0) the In-Place bit in the PROTECTION object of the outgoing Path
   message associated with the terminated recovery LSP.

apparently make dynamic 'overlapping' segment protection impossible.

One scenario that came to my mind was node failure protection
envisioned to be implemented by recovery LSPs for the primary LSP
A-B-C-D-E-F-G, depicted as follows:

                  H ----- I   J ----- K
                 /         \ /         \
          A --- B --- C --- D --- E --- F --- G
           \         / \         / \         /
            L ----- M   N ----- O   P ----- Q

The specified rules apparently inhibit the setup of such overlapping
segment protection LSPs.  Has this been intended ?

(13)  Section 7

As in RFC 4872, Section 17, the first paragraph of Section 7 in
RFC 4873 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.  Where they differ, formats for unidirectional LSPs
   are presented separately from bidirectional LSPs.

It should say:
                                 vvv
|  This section presents the RSVP-TE message related formats as modified
   by this document.  Where they differ, formats for unidirectional LSPs
   are presented separately from bidirectional LSPs.

Rationale:
  'Classic' RSVP (RFC 2205) is neither covered nor affected by the
  subsequently specified (extended) message formats.

Please comment.

IMHO, at least items (11) and (13) should be addressed by and
RFC 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.

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