Subject: RFC 4842 issues and errata

From: Alfred Hönes <[email-masked]>
Date: Thu, 17 May 2007 03:18:29 +0200 (MESZ)

Hello,
after studying the recently published RFC 4842 (CEP)
authored/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.

(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.

Please comment.

At least items (6) and (9) should be addressed by an Errata Note.
Items (10) and (11) need action anyway.
I leave it to your decision which other items should be included
in an Errata Note as well; for some items, it surely depends on
the 'far end' diagnostic results (from my perspective) ...

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