RFC Errata
RFC 4875, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", May 2007
Note: This RFC has been updated by RFC 6510
Source of RFC: mpls (rtg)
Errata ID: 961
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Rejected by: Adrian Farrel
Date Rejected: 2010-08-21
(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. ]
It should say:
[see above]
Notes:
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.
from pending
--VERIFIER NOTES--
Multipart Erratum split into Errata 2481-2494