RFC Errata
Found 9 records.
Status: Verified (4)
RFC 4873, "GMPLS Segment Recovery", May 2007
Note: This RFC has been updated by RFC 9270
Source of RFC: ccamp (rtg)
Errata ID: 1797
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David McWalter
Date Reported: 2009-06-23
Verifier Name: Adrian Farrel
Date Verified: 2010-08-20
Section 5.2 says:
The collection of SRROs is controlled via the segment-recording-desired flag in the SESSION_ATTRIBUTE object. This flag MAY be set even when SEROs are not used.
It should say:
The collection of SRROs is controlled via the presence of an RRO in the message being processed.
Notes:
No request was made to IANA to assign a value for the segment-recording-desired flag.
As reported in the Errata, the segment-recording-desired flag is
unassigned. The flag is unassigned and therefore cannot be used.
As agreed to on the CCAMP mail list and the Stockholm (IETF 75)
working group meeting the the collection of SRROs should be
controlled based on the presence of an RRO in the message being
processed. That is, the segment-recording-desired flag should be
considered to be set when an RRO is present in the message being
processed.
Errata ID: 937
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-08
Verifier Name: Adrian Farrel
Date Verified: 2010-10-30
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 should say:
Recovery LSP removal follows standard procedures defined in [RFC3209] and [RFC3473]. These procedures include LSP removal with and without setting the administrative status flags described in Section 7 of [RFC3473].
Errata ID: 939
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-08
Verifier Name: Adrian Farrel
Date Verified: 2010-10-30
Section 4.3.1 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.
It should say:
o new text: If a message contains multiple NOTIFY_REQUEST objects, only the first object is used to supply the information used to build and send a notification. Subsequent NOTIFY_REQUEST objects MUST be propagated in the order received.
Notes:
The original proposed text (below) is rejected because the presence of the NOTIFY_REQUEST object is not a trigger.
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.
Errata ID: 943
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-08
Verifier Name: Adrian Farrel
Date Verified: 2010-10-30
Section 6.1 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:
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:
Notes:
The subsequent diagram depicts the full object, not only the (new) flags.
Status: Held for Document Update (2)
RFC 4873, "GMPLS Segment Recovery", May 2007
Note: This RFC has been updated by RFC 9270
Source of RFC: ccamp (rtg)
Errata ID: 935
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-08
Held for Document Update by: Adrian Farrel
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. 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. 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. 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. 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. 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. Section 6.2 The last sentence of the third paragraph of Section 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.
It should say:
[see above]
Notes:
editorial nits.
from pending
Errata ID: 941
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-08
Held for Document Update by: Adrian Farrel
Date Held: 2010-10-30
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 that of 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).
Notes:
The proposed text change (below) is rejected in favor of more correct English.
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).
Status: Rejected (3)
RFC 4873, "GMPLS Segment Recovery", May 2007
Note: This RFC has been updated by RFC 9270
Source of RFC: ccamp (rtg)
Errata ID: 936
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-08
Rejected by: Adrian Farrel
Date Rejected: 2010-10-30
Section 4.2.3 says:
In general, objects in a recovery LSP are created based on the corresponding objects in the LSP being protected. [...]
It should say:
[not submitted]
Notes:
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.
from pending
--VERIFIER NOTES--
There has long been a conflation of "LSP" to mean the data plane entity (connection) and the also the control plane state necessary to maintain the data plane entity. The body of people working in the MPLS and CCAMP working groups are used to this and can readily deduce which meaning is intended. Additional text is added when the author believes it is important to make an explicity distinction.
Since this Erratum is not specifically actionable on this RFC, it is rejected.
Errata ID: 944
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-08
Rejected by: Adrian Farrel
Date Rejected: 2010-10-30
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 ?
It should say:
[see above]
Notes:
from pending
--VERIFIER NOTES--
This is not an Erratum. If there is technical discussion to be had about the function enabled or prohibited by the specification, and the requirements for the provision of services in a network, these need to be taken to the CCAMP mailing list and might result in a revision to the RFC or a new draft.
Errata ID: 945
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-08
Rejected by: Adrian Farrel
Date Rejected: 2010-10-30
Section 7 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:
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.
Notes:
Does not confine the scope of the specification as it
would be appropriate.
'Classic' RSVP (RFC 2205) is neither covered nor affected by the
subsequently specified (extended) message formats.
from pending
--VERIFIER NOTES--
Although it is true that there is some common distinction between "classic" RSVP and RSVP-TE, the IP protocol number is the same, and the message numbers (and registry) are the same. In essence, there is just one protocol with two uses.