Subject: RFC 4875 issues and errata

From: Alfred Hönes <[email-masked]>
Date: Wed, 16 May 2007 00:17:17 +0200 (MESZ)

Hello,
after studying the recently published RFC 4875 (P2MP Extensions
to RSVP-TE) edited 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 4.5 -- syntax / punctuation issue

In the first paragraph of Section 4.5, on page 7, RFC 4875 says:
                                           vv
|           [...].  The < [<EXPLICIT_ROUTE>], <S2L_SUB_LSP> > tuple
   represents the S2L sub-LSP and is referred to as the sub-LSP
   descriptor.  [...]

Obviously, the tagged comma should be *inside* the square brackets:
                                           vv
|           [...].  The < [<EXPLICIT_ROUTE>,] <S2L_SUB_LSP> > tuple
   represents the S2L sub-LSP and is referred to as the sub-LSP
   descriptor.  [...]

The same issue recurs in the third paragraph of Section 4.5, on the
same page.

At similar places in the RFC, e.g. in the first paragraph of
Section 5.2.1, the comma is omitted entirely in the tuple notation.
That is very unusual.

(2)  Section 5.2.1 -- typo (text reformatting problem ?)

In the 5th line of the last-paragraph of Section 5.2.1,
    "Sub- Group"   should be spelled   "Sub-Group" .

(3)  Section 6.1 -- bad internal reference, and missing article

Within Section 6.1, the first text lines on page 17 say:

|  The S2L sub-LSP flow descriptor has the same format as S2L sub-LSP
|  descriptor in section 4.1 with the difference that a
   P2MP_SECONDARY_RECORD_ROUTE object is used in place of a P2MP
   SECONDARY_EXPLICIT_ROUTE object.  [...]

The RFC should say, inserting the missing article and correcting
the reference to point to Section 5.1 :

|  The S2L sub-LSP flow descriptor has the same format as the S2L
|  sub-LSP descriptor in section 5.1 with the difference that a
   P2MP_SECONDARY_RECORD_ROUTE object is used in place of a P2MP
   SECONDARY_EXPLICIT_ROUTE object.  [...]

(4)  Section 6.2 -- missing article

The second paragraph of Section 6.2, on mid-page 17, says:

                                 [...].  When the integrity bit is set
|  in the LSP_REQUIRED_ATTRIBUTE object, Resv message MUST NOT be sent
   upstream until all Resv messages have been received from the
   downstream neighbors.

It should say:

                                 [...].  When the integrity bit is set
|  in the LSP_REQUIRED_ATTRIBUTE object, a Resv message MUST NOT be sent
   upstream until all Resv messages have been received from the
   downstream neighbors.

(5)  Section 8.2 -- text duplication and inconsistency

The second paragraph of Section 8.2 (on page 23),

   A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
   object(s) of a Resv message to the value that was received in the
   corresponding Path message.  If any of the incoming Resv messages
   corresponding to a single Path message carry a RESV_CONFIRM object,
   then the LSR MUST include a RESV_CONFIRM object in the corresponding
   Resv message that it sends upstream.  If the Sub-Group Originator ID
   is its own address, then it MUST set the receiver address in the
   RESV_CONFIRM object to this address, else it MUST propagate the
   object unchanged.

should be deleted entirely !

Rationale:
  The first two sentences in this paragraph are repeated almost
  literally in the subsequent (third) paragraph of the section.
  The third (last) sentence above essentially is superseeded, in
  a more precise manner, by the second and the third bullet at the
  bottom of page 23.
  But, perhaps most importantly, the first bullet there handles a
  subcase not covered by, and hence mis-specified, by that sentence!

  Apparently, the lower half of page 23 is a revised revision of
  the quoted second paragraph, which should have been deleted.

(6)  Section 10.2 -- clarification including mismatched angle
                     brackets, word omissions, and punctuation

Within Section 10.2, the third paragraph on page 26 says:

   [...]
|  A newly received Path message that matches SESSION object and Sender
   Tunnel Address, LSP ID, Sub-Group Originator ID> with existing Path
|  state carrying the same or different Sub-Group_ID, referred to Sub-
|  Group_ID(n) is processed as follows:

It should say:

   [...]
|  A newly received Path message that matches in SESSION object and
|  <Sender Tunnel Address, LSP ID, Sub-Group Originator ID> with
|  existing Path state carrying the same or a different Sub-Group_ID,
|  referred to as Sub-Group_ID(n), is processed as follows:

Or even better, a bit reworded for enhanced readability:

   [...]
|  A newly received Path message with SESSION object and <Sender Tunnel
|  Address, LSP ID, Sub-Group Originator ID> tuple matching existing
|  Path state carrying the same or a different Sub-Group_ID, referred to
|  as Sub-Group_ID(n), is processed as follows:

(7)  Section 11.3

Established language in IETF (and other) publications is "tear down",
not simply "tear", when it comes to the deletion of connections etc.

Therefore, while not really wrong, I would have appreciated the
following changes:

- in the 5th line of the 3rd paragraph of Section 11.3 (on page 28):
       "It does not tear any other branches ..."
  -->  "It does not tear down any other branches ..."

- in the 5th paragraph of Section 11.3, in the last text line on p.28:
       "... that are explicitely torn ..."
  -->  "... that are explicitely torn down ..."

[ I note this minor issue just for consideration in the preparation
  of future / derived work. ]

(8)  Section 15.1.2 -- another typo

On page 31, in the 6th line of the first paragraph of Section 15.1.2,

  "being backed- up"  should be  "being backed up"

[ The hyphenated form, "backed-up" is only appropriate in adverbial
  context, e.g., "a backed-up LSP". ]

(9)  Section 16 -- typo/grammar

Within Section 16, the third paragraph on page 34 says:

   There maybe overhead for an operator to configure ...

It should say:

   There may be overhead for an operator to configure ...
            ^

Rationale: Otherwise, the sentence lacks of a verb.

(10)  Section 17 -- bad internal reference

Within Section 17, in the second paragraph on page 35, the reader
is referred to:
                 "Figure 2 in section 24"
which should be:
                 "Figure 2 in Appendix A"

(11)  Section 18 -- typo (text reformatting problem ?)

Within Section 18, at the bottom of page 35,
    "re- merge"  should be  "re-merge"

(12)  Section 19

(12a) -- lack of precision / completeness

The sub-sections of Section 19 mostly remain a bit unspecific with
respect to Class *numbers* (only Section 19.3 does supply these),
whereas C-Type values always are specified fully.

For uniformity and completeness, and for the ease of the reader,
the following changes/amendments (determined after IANA lookup)
should be applied -- adopting the style of the RFC text from
Section 19.3 --, to the lines immediately above the class data
structure diagrams (I use abbreviated, diff-like notation):

o  in Section 19.1.1 (on mid-page 39):

   Class = SESSION, P2MP_LSP_TUNNEL_IPv4 C-Type = 13
--
   SESSION Class = 1, P2MP_LSP_TUNNEL_IPv4 C-Type = 13

o  in Section 19.1.2 (on page 40):

   Class = SESSION, P2MP_LSP_TUNNEL_IPv6 C-Type = 14
--
   SESSION Class = 1, P2MP_LSP_TUNNEL_IPv6 C-Type = 14

o  in Section 19.2.1 (on top of page 41):

   Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv4 C-Type = 12
--
   SENDER_TEMPLATE Class = 11, P2MP_LSP_TUNNEL_IPv4 C-Type = 12

o  in Section 19.2.2 (on top of page 42):

   Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv6 C-Type = 13
--
   SENDER_TEMPLATE Class = 11, P2MP_LSP_TUNNEL_IPv6 C-Type = 13

o  in Section 19.4.1 (at the bottom of page 43):

   Class = FILTER_SPEC, P2MP LSP_IPv4 C-Type = 12
--
   FILTER_SPEC Class = 10, P2MP LSP_IPv4 C-Type = 12

o  in Section 19.4.2 (at the top of page 44):

   Class = FILTER_SPEC, P2MP LSP_IPv6 C-Type = 13
--
   FILTER_SPEC Class = 10, P2MP LSP_IPv6 C-Type = 13

o  in Section 19.5 (on page 44):

                       The class of the P2MP SERO is the same as the
   SERO defined in [RFC4873].
--
                       The class of the P2MP SERO is 200, as assigned
   for the SERO in [RFC4873].

o  in Section 19.6 (on page 44):

                The class of the P2MP SRRO is the same as the SRRO
   defined in [RFC4873].
--
                The class of the P2MP SRRO is 201, as assigned for
   the SRRO in [RFC4873].

(12b) -- unusual presentation

It is unusual to present the explanations of fields in a diagram
in a sequence that does not correspond to the sequence of the
fields therein.

Therefore, I would have appreciated it to find ...

o  in Section 19.2.1 (on page 41) the explanation for "LSP ID"
   not at the bottom of the list, but at the second position,
   below the explanation for "IPv4 tunnel sender address";

and

o  in Section 19.2.2 (on page 42) the explanation for "LSP ID"
   not at the bottom of the list, but at the second position,
   below the explanation for "IPv6 tunnel sender address";

(13)  Section 20.2 -- similar to (12a)

Contrary to Section 20.1, Section 20.2 is silent about the class
numbers.  As in item (12a) above, for consistency and completeness,
the following changes should be applied, in accordance with the
style of the IANA registry file and Section 20.1 :

   Class Name = SESSION
--
     1  Class Name = SESSION

   Class Name = SENDER_TEMPLATE
--
    11  Class Name = SENDER_TEMPLATE

   Class Name = FILTER_SPEC
--
    10  Class Name = FILTER_SPEC

   Class Name = SECONDARY_EXPLICIT_ROUTE (Defined in [RFC4873])
--
   200  Class Name = SECONDARY_EXPLICIT_ROUTE

   Class Name = SECONDARY_RECORD_ROUTE (Defined in [RFC4873])
--
   201  Class Name = SECONDARY_RECORD_ROUTE

[ Note:
  I have deleted the repeated refs to RFC 4873 for uniformity;
  this information is already present in Section 19, it might
  only have been interesting here for the IANA in the I-D phase. ]

Please comment.

I strongly recommend to at least address items (3), (5), (6),
and (10) by an RFC Errata Note; I leave it to your decision which
other items to include additionally; IMHO, items (1), (12a), and
(13) should get high priority among these.

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.

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