RFC Errata
Found 5 records.
Status: Verified (4)
RFC 4842, "Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)", April 2007
Source of RFC: pwe3 (int)
Errata ID: 1064
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-17
Section 11.2.1.1 says:
The 28 bits of the EBM are divided into groups of 4 bits, each corresponding to a different VTG within the STS container. All 4 bits are used to indicate whether VT1.5 (T1) tributaries are carried within a VTG. The first 3 bits read from right to left are used to indicate whether VT2 (E1) tributaries are carried within a VTG. The first 2 bits are used to indicate whether VT3 (DS1C) tributaries are carried within a VTG.
It should say:
The 28 bits of the EBM are divided into groups of 4 bits, each corresponding to a different VTG within the STS container. All 4 bits are used to indicate whether VT1.5 (T1) tributaries are carried within a VTG. The 3 rightmost bits in a bit group are used to indicate whether VT2 (E1) tributaries are carried within a VTG. The 2 rightmost bits in a bit group are used to indicate whether VT3 (DS1C) tributaries are carried within a VTG.
Notes:
Replaced 'first 3 bits read from right to left' with '3 rightmost
bits' and similarly 'first 2 bits' with '2 rightmost bits'. The
new text avoids possible confusion with regards to the position
of the relevant bits.
from pending
Errata ID: 1065
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-17
Date Verified: 2011-02-01
Report Text:
The notation B*3 was replaced with the notation B3* which is consistent with the definitions. from pending
Errata ID: 1066
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-17
Section 11.2.3.2 says:
All 4 bits are used to indicate whether VC-11 (T1)
tributaries are carried within a TUG-2. The first 3 bits read right
to left are used to indicate whether VC-12 (E1) tributaries are
carried within a TUG-2. The first bit is used to indicate that a
VC-2 is carried within a TUG-2.
It should say:
All 4 bits are used to indicate whether VC-11 (T1)
tributaries are carried within a TUG-2. The rightmost 3 bits are
used to indicate whether VC-12 (E1) tributaries are carried within a
TUG-2. The rightmost bit is used to indicate that a VC-2 is carried
within a TUG-2.
Notes:
Replaced 'first 3 bits read from right to left' with '3 rightmost
bits' and similarly 'first 2 bits' with '2 rightmost bits'. The
new text avoids possible confusion with regards to the position
of the relevant bits.
from pending
Errata ID: 6718
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lars Eggert
Date Reported: 2021-10-21
Verifier Name: Martin Vigoureux
Date Verified: 2021-11-03
Section 18.1 says:
[RTP] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3005, July 2003.
It should say:
[RTP] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
Notes:
The RFC number for [RTP] should be 3550, not 3005.
Status: Rejected (1)
RFC 4842, "Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)", April 2007
Source of RFC: pwe3 (int)
Errata ID: 981
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-17
Rejected by: Ron Cohen
Date Rejected: 2007-05-17
(0) Title of the RFC <--> Scope / applicability (Section 2)
The second paragraph of Section 2 says:
This document provides encapsulation formats and semantics for
| emulating SONET/SDH circuits and services over MPLS packet-switched
networks (PSNs). [...]
^^^^
Up to now, pseudowire encapsulations (and signaling protocol elements)
have been defined for MPLS and L2TPv3 in the data plane.
Previous PWE3 documents had developed a clear language for their scope,
saying (omitting the canonical expansion of acronyms),
"... over MPLS [Networks]",
"... over L2TPv3", or
"... over Packet [Networks]" iff applicable to MPLS *and* L2TPv3.
Confusingly and unfortunately, the title of RFC 4842 breaks that
clear naming scheme.
(1) Section 4 -- acronym expansion
On page 5, Section 4 of RFC 4842 contains the lines:
vvvv
| STM-n Synchronous Transport Module-n (SDH)
STS-n Synchronous Transport Signal-n (SONET)
I'm getting confused.
>From most publicly available sources, I've been accustomed to expect:
vvv
| STM-n Synchronous Transfer Module-n (SDH)
STS-n Synchronous Transport Signal-n (SONET)
So, what's true? Please check.
(2) Section 5.2 -- missing article
The first paragraph of Section 5.2, near the bottom of page 7, says:
v
| The CEP header supports both a basic and extended mode. The Basic
CEP header provides the minimum functionality necessary to accurately
emulate a SONET/SDH circuit over a PSN. [...]
It should say:
vvvv
| The CEP header supports both a basic and an extended mode. The Basic
CEP header provides the minimum functionality necessary to accurately
emulate a SONET/SDH circuit over a PSN. [...]
(3) Section 5.3
(3a) -- missing article
In the lower half of page 10, Section 5.3 contains the explanation:
Sequence Number [0:15]: The packet sequence number MUST continuously
cycle from 0 to 0xFFFF. It is generated and processed in
accordance with the rules established in [RTP]. The CEP receiver
MUST sequence packets according to the Sequence Number field of
| the CEP header and MAY verify correct sequencing using RTP
Sequence Number field.
^
It should say:
Sequence Number [0:15]: The packet sequence number MUST continuously
cycle from 0 to 0xFFFF. It is generated and processed in
accordance with the rules established in [RTP]. The CEP receiver
MUST sequence packets according to the Sequence Number field of
| the CEP header and MAY verify correct sequencing using the RTP
Sequence Number field.
^^^^^
(3b) -- surprising timestamp clock frequency
The next bullet on page 10 says:
Timestamp [0:31]: Timestamp values are used in accordance with the
rules established in [RTP]. Frequency of the clock used for
| generating timestamps MUST be 19.44 MHz based on a local
reference.
^^^^^^^^^
This frequency value is surprising (for me).
I could not derive any immediate relationship to wellknown SONET/SDH
bit or frame rates, etc. -- cf. Tables 4 & 5 in Appendix A of the RFC.
If the specified value is correct, please give me a hint on its origin;
otherwise, please have it corrected in an RFC Errata Note.
(4) Section 10.1 -- missing article
Within Section 10.1, in the second paragraph on page 20, the RFC says:
v
| UAS-CEP SHALL be declared after configurable number of consecutive
SES-CEP, and cleared after a configurable number of consecutive
seconds without SES-CEP. Default value for each is 10 seconds.
It should say:
vvv
| UAS-CEP SHALL be declared after a configurable number of consecutive
SES-CEP, and cleared after a configurable number of consecutive
seconds without SES-CEP. Default value for each is 10 seconds.
(5) Section 11.2.1.1 -- confusing bit field specifications
In Section 11.2.1.1, Figure 7 and the long paragraph extending from
the bottom of page 23 to the top of page 24 say:
The STS-1 EBM has the following format:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VTG7 | VTG6 | VTG5 | VTG4 | VTG3 | VTG2 | VTG1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Equipped Bit Mask (EBM) for Fractional STS-1
The 28 bits of the EBM are divided into groups of 4 bits, each
corresponding to a different VTG within the STS container. All 4
bits are used to indicate whether VT1.5 (T1) tributaries are carried
| within a VTG. The first 3 bits read from right to left are used to
indicate whether VT2 (E1) tributaries are carried within a VTG. The
| first 2 bits are used to indicate whether VT3 (DS1C) tributaries are
| carried within a VTG. The rightmost bit is used to indicate whether
a VT6 (DS2) is carried within the VTG. The VTs within the VTG are
numbered from right to left, starting from the first VT as the first
bit on the right. For example, the EBM of a fully occupied STS-1
<< page break >>>
with VT1.5 tributaries is all ones, while that of an STS-1 fully
occupied with VT2 (E1) tributaries has the binary value
| 0111011101110111011101110111.
Ooops!
a)
If you have a numbered bit field, e.g., the VTG7 field:
0 1 2 3 4 5
+-+-+-+-+-+-+-
| VTG7 | ...
+-+-+-+-+-+-
and denote the binary representation of its value accordingly:
<vtg7> = < b0, b1, b2, b3 >,
then "The *first* 3 bits read from right to left", apparently
specifies the number with the (bit-reversed) binary representation
< b2, b1, b0 > .
That does not correspond to the final example given, and it is not
really compatible with the last sentence before the page break.
Similarly, "the first 2 bits" used for VT3 / DS1C would be
< b0, b1 > -- or should it be (again, bit-revered) < b1, b0 > ??
Finally, "the rightmost bit" is used for VT6 / DS2, i.e. < b3 > .
That seems fuzzy, at best.
Assuming that the example is correct, I strongly suspect that the
'active' bit groups are intended to be right justified in the 4-bit
groups, in any case, und that thus text above in fact should say:
The 28 bits of the EBM are divided into groups of 4 bits, each
corresponding to a different VTG within the STS container. All 4
bits are used to indicate whether VT1.5 (T1) tributaries are carried
| within a VTG. The 3 rightmost bits in a bit group are used to
| indicate whether VT2 (E1) tributaries are carried within a VTG.
| The 2 rightmost bits in a bit group are used to indicate whether
| VT3 (DS1C) tributaries are carried within a VTG. The rightmost bit
is used to indicate whether a VT6 (DS2) is carried within the VTG.
The VTs within the VTG are numbered from right to left, starting from
the first VT as the first bit on the right. [...]
b)
Further confusion arises from the fact that the above specification
overloads the field in a four-fold way but does not give any hint
as to how this overloading is encoded / disambiguated.
I've scratched my head for quite a time, looking for the appropriate
hooks to properly decode the field.
Much later in the text, it eventually turns out that this information
must be signalled out-of-band.
For clarity and precision, this fact should have been stated clearly
within Section 11.2.1.1.
(6) Section 11.2.1.2
There's a mismatch in the notation between the formula given in
Section 11.2.1.2, on mid-page 24, and the subsequent explanations.
The RFC says:
vvv
| B3[i]'(t) = B3[i](t-1) || B3[i]'(t-1) || B3[i](t) || B*3[i](t-1)
| Where:
B3[i] = the existing B3[i] value in the incoming signal
B3[i]' = the new (compensated) B3[i] value
| B3*[i] = the B3[i] value of the unequipped VTs in the
incoming signal
|| = exclusive OR operator
t = the time of the current frame
t-1 = the time of the previous frame
IMHO, the notation 'B3*[i]' , as explained is the proper notation,
and the 'B*3' in the formula should be changed accordingly.
Furthermore, the second line should be 'editorially reworked' for
proper indentation (as the text above and below) and capitalization.
Hence, the RFC should say:
vvv
| B3[i]'(t) = B3[i](t-1) || B3[i]'(t-1) || B3[i](t) || B3*[i](t-1)
| where:
B3[i] = the existing B3[i] value in the incoming signal
B3[i]' = the new (compensated) B3[i] value
B3*[i] = the B3[i] value of the unequipped VTs in the
incoming signal
|| = exclusive OR operator
t = the time of the current frame
t-1 = the time of the previous frame
(7) Section 11.2.2.1 -- missing article
The last paragraph of Section 11.2.2.1, at the bottom of page 25,
says:
A T3 is encapsulated asynchronously into a VC-3 container as
| described in Section 10.1.2.1 of [G.707]. VC-3 container has only 85
data columns, which is identical to the STS-1 container with the two
fixed stuff columns 30 and 59 removed. Other than that, the mapping
is identical.
It should say:
vv
A T3 is encapsulated asynchronously into a VC-3 container as
| described in Section 10.1.2.1 of [G.707]. A VC-3 container has only
85 data columns, which is identical to the STS-1 container with the
two fixed stuff columns 30 and 59 removed. Other than that, the
mapping is identical.
(8) Section 11.2.3.1 -- onother missing article
The third paragraph of Section 11.2.3.1, near the bottom of page 27,
says:
v
| [...]. This is the equivalent of multiplexing 7 VTGs within STS-1
container in SONET terminology, except for the location of the fixed
columns.
It should say:
vvvv
| [...]. This is the equivalent of multiplexing 7 VTGs within an STS-1
container in SONET terminology, except for the location of the fixed
columns.
(9) Section 11.2.3.2
(9a) -- bad term / extraneous word
The first paragraph of Section 11.2.3.2, on top of page 28, says:
The fractional VC-4 CEP header uses the VC-4 CEP header defined in
this document. Optionally, an additional 12-byte header extension
| word is added.
^^^^^
It should say:
The fractional VC-4 CEP header uses the VC-4 CEP header defined in
this document. Optionally, an additional 12-byte header extension
| is added.
Rationale: There are no such "12-byte words", AFAICS.
(9b) -- confusing bit field specifications, again
Similar issues as explained in item (5) above also hold for the (long)
second paragraph below Figure 10, on mid-page 29.
Again, I strongly suspect that the text,
[...]. All 4 bits are used to indicate whether VC-11 (T1)
| tributaries are carried within a TUG-2. The first 3 bits read right
| to left are used to indicate whether VC-12 (E1) tributaries are
| carried within a TUG-2. The first bit is used to indicate that a
VC-2 is carried within a TUG-2. The VCs within the TUG-2 are
numbered from right to left, starting from the first VC as the first
bit on the right. For example, [...]
in fact should say:
[...]. All 4 bits are used to indicate whether VC-11 (T1)
| tributaries are carried within a TUG-2. The rightmost 3 bits are
used to indicate whether VC-12 (E1) tributaries are carried within a
| TUG-2. The rightmost bit is used to indicate that a VC-2 is carried
within a TUG-2. The VCs within the TUG-2 are numbered from right to
left, starting from the first VC as the first bit on the right. For
example, [...]
(9c) -- typo / singular/plural mismatch
The last paragraph of Section 11.2.3.2, near the bottom of page 29,
says:
vv
| [...]. The A bit indicate the reason for removal of the
entire TUG-3 columns. [...]
It should say:
vvv
| [...]. The A bit indicates the reason for removal of the
entire TUG-3 columns. [...]
(10) Section 12 -- item (0) and its bad consequences
In Section 12, we unfortunately return to the issue explained in
item (0) above.
Within Section 12, the first paragraph on page 31 says:
The PW Type field in PWid Forwarding Equivalence Class (FEC) and PW
| generalized ID FEC elements MUST be set to SONET/SDH Circuit
| Emulation over Packet (CEP) [PWE3-IANA].
In RFC 4446 [PWE3-IANA], on page 3, I find *two* assignments:
PW type Description Reference
===================================================================
0x0008 SONET/SDH Circuit Emulation Service Over MPLS [CEP]
0x0010 SONET/SDH Circuit Emulation over Packet [CEP]
Hence, apparently Section 12 refers to PW type 0x0010.
Because there is an independent 'PW type' namespace for L2TPv3 and
RFC 4446 was MPLS-specific (although its title didn't say so!),
it could be concluded from the above that PW type 0x0010 was
intended for use over MPLS *and* L2TPv3, with a corresponding
assignment for L2TPv3 to be performed in another document, whereas
PW type 0x0008 apparently was reserved for an MPLS specific CEP
solution, and both were expected to be specified in the same document.
Since RFC 4842 is MPLS-only, it could be expected that it would
make use of that MPLS-specific PW type, 0x0008, not of 0x0010 !
Therefore, the above quoted text in Section 12 comes to great
surprise!
The IANA registry (today) still lists theses two lines as above,
where [CEP] is:
[CEP] "SONET/SDH Circuit Emulation Service Over Packet (CEP)",
draft-ietf-pwe3-sonet-11.txt (work in progress)
Therefore: What's the matter here ?
Apparently, RFC 4842 *is* the successor ot that I-D.
Has PW type 0x0008 been abandoned ?
Or is Section 12 wrong, and it should refer to PW type 0x0008 ?
In former case, the IANA registry should be updated, deprecating and
perhaps permanently reserving 0x0008, and 0x0010 should be renamed
to reflect its use (and all that should have been noted in Section 15
of RFC 4842!), e.g.:
PW type Description Reference
===================================================================
0x0008 - deprecated - / -reserved - [IESG]
0x0010 SONET/SDH Circuit Emulation over MPLS [RFC4842]
(11) Section 15 -- omissions
As explained in the preceding item, IANA has not properly updated
the pwe3-parameters registry upon publication od RFC 4842.
This is certainly due to missing instructions in Section 15,
which merely states (on page 35):
IANA considerations for pseudowires are covered in [PWE3-IANA]. CEP
does not introduce additional requirements from IANA.
This section should have been instructed to link one of the above
mentioned PW types to RFC 4842, and perform the intended disposition
with the other one.
Whatever the plans currently are, the IANA registry should be
updated accordingly and as soon as possible, to reduce the confusion.
(12) Appendix A -- incomplete information
On mid-page 36, just below Table 4, Appendix A says:
[...]
A number of STS-1s may also be linked together to form a super-rate
| signal with only one SPE. The optical super-rate signal is denoted
as OC-Nc, which has a higher payload capacity than OC-N.
For completeness and clarity, the super-rate signal mentioned should
be named. According to the layman's guess (please correct if I am
wrong!), the RFC should say:
[...]
A number of STS-1s may also be linked together to form a super-rate
| signal denoted STS-Nc, with only one SPE. The optical super-rate
signal is denoted as OC-Nc, which has a higher payload capacity than
OC-N.
It should say:
[see above]
Notes:
Authors sent email about those that should be posted. They were posted as verified; the others are rejected.
from pending