RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 10 records.

Status: Verified (3)

RFC 4717, "Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks", December 2006

Source of RFC: pwe3 (int)

Errata ID: 2257

Status: Verified
Type: Technical

Reported By: Ron Insler
Date Reported: 2010-05-13
Verifier Name: Stewart Bryant
Date Verified: 2011-08-05

Section 7.2 says:

7.2.  VPC Case

   When configured for a VPC cell relay service, both PEs SHOULD act as
   a VP cross-connect in accordance with the OAM procedures defined in
   [I.610].

   The PEs SHOULD be able to process and pass the following OAM cells
   transparently according to [I.610]:

     - F4 AIS (segment and end-to-end)
     - F4 RDI (segment and end-to-end)
     - F4 loopback (segment and end-to-end)

It should say:

7.2.  VPC Case

   When configured for a VPC cell relay service, both PEs SHOULD act as
   a VP cross-connect in accordance with the OAM procedures defined in
   [I.610].

   The PEs SHOULD be able to process and pass the following OAM cells
   transparently according to [I.610]:

     - F4 AIS (segment and end-to-end)
     - F4 RDI (segment and end-to-end)
     - F4 loopback (segment and end-to-end)
     - F4 CC (segment and  end-to-end)

Notes:

As per [I.610] all OAM cells must be transferred transparently , RFC 4717 does not mentioned the F4 CC OAM cell .

Errata ID: 2920

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2007-10-17
Verifier Name: Stewart Bryant
Date Verified: 2011-08-05

 


(10b)
The T bit explanation (in the lower half of page 27) contains
misleading and inappropriate wording related to Figure 4.
Figure 4 generally applies for both the proper AAL5 CPCS-SDU payload
or the case of an ATM OAM cell payload.  Furthermore, it should be
noted that Section 8.1 (which contains and explains Figure 4)
specifies the Flags field as 'reserved, should be set to 0'.
This is incompatible with the subsequent text that requires the T bit
to be set to 1 for an OAM cell.  Therefore, to avoid confusion,
the clause referencing to Figure 4 should better be deleted from
the T bit explanation.

Hence, the text,

       Bit (T) of the control word indicates whether the packet contains
       an ATM admin cell or an AAL5 payload.  If T = 1, the packet
|      contains an ATM admin cell, encapsulated according to the N-to-
|      one cell relay encapsulation, Figure 4.  If not set, the PDU
       contains an AAL5 payload.  The ability to transport an ATM cell
       in the AAL5 SDU mode is intended to provide a means of enabling
       administrative functionality over the AAL5 VCC (though it does
       not endeavor to preserve user-cell and admin-cell
       arrival/transport ordering).

should say:

       Bit (T) of the control word indicates whether the packet contains
       an ATM admin cell or an AAL5 payload.  If T = 1, the packet
|      contains an ATM admin cell.  If T = 0, the PDU contains an AAL5
       payload.  The ability to transport an ATM cell in the AAL5 SDU
       mode is intended to provide a means of enabling administrative
       functionality over the AAL5 VCC (though it does not endeavor to
       preserve user-cell and admin-cell arrival/transport ordering).


Notes:

This is section 10(b) from Erratum 999

Errata ID: 2922

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2007-10-17
Verifier Name: Stewart Bryant
Date Verified: 2011-08-05

 



(12)  Section 11.2.1 -- internal mis-ref.

The 3rd bullet in Section 11.2.1, near the bottom of page 30, says:

     - The E and C bits of the fragment shall be set as defined in
|      section 9.
               ^
It should say:

     - The E and C bits of the fragment shall be set as defined in
|      section 11.1.
               ^^^^

Rationale:
  As explained above for item (11a), the specification of these bits in
  Section 11.1 is contrary to their (hidden) use in Sections 8 and 9.


                                          ^

(14)  Section 12 -- internal mis-refs

The last paragraph of Section 12 (on page 32) says:

   In both the ATM-to-PSN and PSN-to-ATM directions, the method used to
   transfer the CLP and EFCI information of the individual cells into
   the ATM-specific field, or flags, of the PW packet is described in
|  detail in sections 6 through 9 for each encapsulation mode.
                      ^         ^
It should say:

   In both the ATM-to-PSN and PSN-to-ATM directions, the method used to
   transfer the CLP and EFCI information of the individual cells into
   the ATM-specific field, or flags, of the PW packet is described in
|  detail in sections 8 through 11 for each encapsulation mode.
                      ^         ^^


Notes:

This is elements 12 and 14 of erratum 999

Status: Held for Document Update (2)

RFC 4717, "Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks", December 2006

Source of RFC: pwe3 (int)

Errata ID: 2917

Status: Held for Document Update
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2007-10-17
Held for Document Update by: Stewart Bryant
Date Held: 2011-08-05

 




(2)  Section 5.1.2 -- misleading specification due to omission.

On top of page 9, Section 5.1.2 says:

   The next 4 bits provide space for carrying protocol-specific flags.
   These are defined in the protocol-specific details below.
|
|  The next 6 bits provide a length field, which is used as follows:
   [...]

'The next 6 bits' is misleading; as indicated in the (unnumbered)
figure at the bottom of page 8, there is a 2-bit 'Res' field between
the Flags field and the Length field; unfortunately, the text lacks
any description of that field.
To fill this gap, the above text should be amended to say:

   The next 4 bits provide space for carrying protocol-specific flags.
   These are defined in the protocol-specific details below.

|  The subsequent 2-bit Res field is reserved; it SHOULD be set to 0
|  by the sending PE and ignored by the receiving PE.
|
|  The next 6 bits provide a length field, which is used as follows:
   [...]

Note: 'SHOULD' is appropriate as future (optional) specifications
      might assign semantics to that field.


(3)  Section 5.4 -- word omission

Section 5.4 (on page 10 of RFC 4717) says:

   The setting of the TTL value in the PW label is application
|  dependent.  In any case, [RFC3032] TTL processing procedure,
   including handling of expired TTLs, MUST be followed.

It should say:

   The setting of the TTL value in the PW label is application
|  dependent.  In any case, the [RFC3032] TTL processing procedure,
   including handling of expired TTLs, MUST be followed.


(4)  Section 6.3 -- word omission

On page 14, Section 6.3 of RFC 4717 contains the numbered item:

|      -iv. The Length of AAL5 frame may exceed the MTU of the PSN.
            This requires fragmentation, which may not be available to
            all nodes at the PW endpoint.

The RFC should say:

|      -iv. The Length of an AAL5 frame may exceed the MTU of the PSN.
            This requires fragmentation, which may not be available to
            all nodes at the PW endpoint.


(5)  Section 7.4 -- distorting typo

The initial text of Section 7.4 (on page 17 of RFC 4717) contains
the line:

|    - (b) On the ATM side of the PW
                                  ^^
This is misleading.  It certainly should say:

|    - (b) On the ATM side of the PE
                                  ^^

(6)  Section 8 -- misleading short text / lack of precision

Section 8 of RFC 4717 (on page 18) says:

   The N-to-one mode (N >= 1) described in this document allows a
   service provider to offer an ATM PVC- or SVC-based service across a
   network.  The encapsulation allows multiple ATM VCCs or VPCs to be
   carried within a single PSN tunnel.  A service provider may also use
   N-to-one mode to provision either one VCC or one VPC on a tunnel.
   This section defines the VCC and VPC cell relay services over a PSN
   and their applicability.

For clarity and added precision, it should say:

   The N-to-one mode (N >= 1) described in this document allows a
   service provider to offer an ATM PVC- or SVC-based service across a
|  packet switched network.  The encapsulation allows multiple ATM VCCs
   or VPCs to be carried within a single PSN tunnel.  A service provider
   may also use N-to-one mode to provision either one VCC or one VPC on
   a tunnel.  This section defines the VCC and VPC cell relay services
   over a PSN and their applicability.


(7)  Section 8.1 -- various clarifications


(7b)  inprecise wording not reflecting requirements language elsewhere

In Section 8.1, the 3rd paragraph below Figure 4 (on mid-page 19)
says:

|  As shown above, in Figure 4, the ATM Control Word is inserted before
|  the ATM service payload.  It may contain a length field and a
   sequence number field in addition to certain control bits needed to
   carry the service.

Taken literally, this text is misleading and partially contradicts
the requirements specified in Section 5.1 (in the second paragraph
on page 7).  In particular, the entire ATM control word (the 3rd word
in Figure 4) is optional, and *not* the various bit fields therein.
To properly reflect these requirements, the RFC should says instead:

|  As shown above, in Figure 4, the optional ATM Control Word (if
|  present) is inserted before the ATM service payload. It contains a
   length field and a sequence number field in addition to certain
   control bits needed to carry the service.

(7c)  bad grammar

Within Section 8.1, the last paragraph on page 20 says:

     * When multiple VCCs or VPCs are transported in one pseudowire,
       VPI/VCI values MUST be unique.  When the multiple VCCs or VPCs
|      are from different a physical transmission path, it may be
                         ^^^                          ^
       necessary to assign unique VPI/VCI values to the ATM connections.
       If they are from the same physical transmission path, the VPI/VCI
       values are unique.

It should say:

     * When multiple VCCs or VPCs are transported in one pseudowire,
       VPI/VCI values MUST be unique.  When the multiple VCCs or VPCs
|      are from different physical transmission paths, it may be
                         ^                          ^^
       necessary to assign unique VPI/VCI values to the ATM connections.
       If they are from the same physical transmission path, the VPI/VCI
       values are unique.



(8)  Sections 9.3 ff. -- alignment flaws in artwork

(8a)
Within Section 9.3, the top part of Figure 8 on page 24 contains
a misaligned border;

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               PSN Transport Header (As Required)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |                      Pseudowire Header                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | [...]

should be:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               PSN Transport Header (As Required)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |                      Pseudowire Header                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | [...]

The same flaw recurs ...

(8b)  within Section 9.4.1, in Figure 9 on page 25;
(8c)  within Section 9.4.1, in Figure 10 on page 26;
(8d)  within Section 11.1, in Figure 12 on page 29;


(9)  Section 9.4.1 -- word omission

On mid-page 25, the bullet,

     * VCI Bits

|      The 16-bit Virtual Circuit Identifier (VCI) incorporates ATM
       Layer VCI value of the cell.

should say:

     * VCI Bits

|      The 16-bit Virtual Circuit Identifier (VCI) incorporates the ATM
       Layer VCI value of the cell.


(10)  Section 10.1 -- multiple mis-specifications

(10a)
As will be explained below, the initial part of Section 10.1
(on page 27) comprises several issues.

The RFC says:

|  The AAL5 CPCS-SDU is prepended by the following header:

    0                   1                   2                   3
    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 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |  Res  |T|E|C|U|Res|  Length   |   Sequence Number (Optional)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              "                                |
   |                     ATM cell or AAL5 CPCS-SDU                 |
   |                              "                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 11: AAL5 CPCS-SDU Encapsulation

It should say:

|  The AAL5 CPCS-SDU or OAM cell is prepended the ATM Control Word:

    0                   1                   2                   3
    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 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |0 0 0 0|T|E|C|U|Res|  Length   |     Sequence Number (or 0)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|    Figure 11: Control Word used with AAL5 CPCS-SDU Encapsulation

Rationale:

(a.1)
The text is wrong and misleading; the figure does not (merely) show
'the prepended header' (i.e., the "ATM Control Word", according to
other parts of this RFC), but the payload as well!
The top level structure of the encapsulation is specified in Figure 4;
hence, it suffices to specify the details of the Control Word here.
Accordingly, the above replacement omits the payload and presents
a modified figure caption.

(a.2)
The 4 most significant bits of the ATM Control Word MUST be all zero.
Denoting the field as 'reserved' is misleading; future specifications
MUST NOT change the value.  See Section 5.1.2 of this RFC, RFC 4385,
and the recently published RFC 4928 for additional explanation!

(a.3)
The 'Sequence Number' field is *not* optional in the control word,
as erroneously might be deduced from the original version of the
figure; it MUST always be present; according to Section 5.1.2, only
the *processing* of this field is optional, and the reserved value 0
is *not* a valid sequence number; it indicates non-use of sequence
number processing.  Hence, the lower half of the ATM Control Word
either contains a sequence number or 0.


(10c)  incomplete specification

The description of the fields in Figure 11 is incomplete.
As a service to the reader, for completeness the following
text should be added at the end of Section 10.1:

|  For a description of the Length and Sequence Number fields, see
|  Section 5.1.2.


(11)  Section 11.1 -- surprising/confusing specification details

(11b)  lack of precision

Below Figure 12, the RFC text on page 29 says:

   The M, V, Res, and C bits are as defined earlier for VCC One-to-one
   cell mode.

For clarity and completeness, it should say:

   The M, V, Res, and C bits are as defined earlier for VCC One-to-one
|  cell mode.  M must be set to 1 and V must be set to 0 for AAL5 PDU
|  Encapsulation; further details regarding the C bit are given below.




(13)  Section 11.2.2 -- significant typo (wrong bit field name)

Section 11.2.2 (on page 31) contains the bullet:

      -iii. The least significant bit for the last ATM cell in the PSN
|           frame is set to the value of the UU bit of Figure 12.
                                             ^^
It should say:

      -iii. The least significant bit for the last ATM cell in the PSN
|           frame is set to the value of the U bit of Figure 12.
                                             ^


(15)  Abuse of language

'AAL5' stands for "ATM Adaptation Layer 5".  Hence, the wording
"ATM AAL5" is a replication considered a rough abuse of language.

All occurrences of "ATM AAL5" in the RFC should be corrected to "AAL5".

Notes:

This is sections 2, 3, 4, 5, 6, 7b, 7c, 8, 9, 10(a), 10(a1), 10(a2), 10(a3), 10(c), 11(b), 13, and 15 of errata 999

Errata ID: 2079

Status: Held for Document Update
Type: Editorial

Reported By: Hu Haitao
Date Reported: 2010-03-18
Held for Document Update by: Stewart Bryant

Section 6.3 says:

       -ii. If the ALL5 PDU is scrambled using ATM security standards, a
            PE will not be able to extract the ALL5 SDU, and therefore
            the whole PDU will be dropped.

It should say:

       -ii. If the AAL5 PDU is scrambled using ATM security standards, a
            PE will not be able to extract the AAL5 SDU, and therefore
            the whole PDU will be dropped.

Status: Rejected (5)

RFC 4717, "Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks", December 2006

Source of RFC: pwe3 (int)

Errata ID: 605

Status: Rejected
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2007-10-17
Rejected by: Stewart Bryant
Date Rejected: 2011-08-03

Section 5.1.1 says:

- ATM One-to-one Cell Mode
- AAL5 PDU Frame Mode

It should say:

- ATM One-to-one Cell Mode  - PW Types: 0x000C and 0x000D
- AAL5 PDU Frame Mode       - PW Type:  0x000E

Notes:


--VERIFIER NOTES--
The author has correctly named the PW types and the reader can find the numeric identifier in both RFC4446 and the IANA registry. Thus the restatement of the numeric identifier is unnecessary.

Errata ID: 999

Status: Rejected
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2007-10-17
Rejected by: Stewart Bryant
Date Rejected: 2011-08-05

 

(1)  incomplete/missing specification of PW types

RFC 4446 (by means of reference update from drafts to published RFCs)
and the IANA "pwe3-parameters" registry refer to this document for
the allocation and description of a couple of (MPLS) Pseudowire Types.
Therefore, this memo should be explicit, precisely give the proper
information, and not leave the reader alone with some apparent
ambiguities in the registry.  (Unfortunately, the RFC uses
descriptive text labels for the PW types that do not match the
text listed as the 'Descriptions' in the MPLS PW Type registry.)

Excluding the PW type 0x001E assigned for the MFA, IANA lists seven
ATM PW types.  I (hopefully) was able to identify most of these in
RFC 4717, but the role of PW type 0x0003 initially remained unclear;
this gap in the meantime has been closed by RFC 4816, taking over
the 'ownership' for that PW type.

To fill in the gap, the following clarifications should be posted
in an RFC errata note for RFC 4717 (please correct if I'm wrong);
because there also is a L2TPv3 Pseudowire Type (sub-)registry
(in the IANA "l2tp-parameters" registry) I also use the precise
term, "MPLS PW Type", in the proposed clarifications.

(1a)  Section 5.1.1

The initial text of Section 5.1.1 (on page 7 of RFC 4717) says:

   This control word is used in the following encapsulation modes:

     - ATM One-to-one Cell Mode
     - AAL5 PDU Frame Mode

It should say:

   This control word is used in the following encapsulation modes:

|    - ATM One-to-one Cell Mode  - MPLS PW types 0x000C and 0x000D
|    - AAL5 PDU Frame Mode       - MPLS PW type 0x000E

(1b)  Section 5.1.2

The initial text of Section 5.1.2 (on page 8 of RFC 4717) says:

   This control word is used in the following encapsulation modes:

     - ATM N-to-one Cell Mode
     - AAL5 SDU Frame Mode

It should say:

   This control word is used in the following encapsulation modes:

|    - ATM N-to-one Cell Mode  - MPLS PW types 0x0009 and 0x000A
|    - AAL5 SDU Frame Mode     - MPLS PW type 0x0002

(1c)  see item (6a) below!

(1d)  missing IANA Considerations

NOTE:
  Would the above clarifications have been included in the RFC,
  it should also have contained an IANA Considerations Section.
  In the meantime, after some complaints and interventions, the
  IANA "pwe3-parameters" registry has been updated to contain the
  proper pointers to RFC 4717 for the abovementioned six PW Types.


(2)  Section 5.1.2 -- misleading specification due to omission.

On top of page 9, Section 5.1.2 says:

   The next 4 bits provide space for carrying protocol-specific flags.
   These are defined in the protocol-specific details below.
|
|  The next 6 bits provide a length field, which is used as follows:
   [...]

'The next 6 bits' is misleading; as indicated in the (unnumbered)
figure at the bottom of page 8, there is a 2-bit 'Res' field between
the Flags field and the Length field; unfortunately, the text lacks
any description of that field.
To fill this gap, the above text should be amended to say:

   The next 4 bits provide space for carrying protocol-specific flags.
   These are defined in the protocol-specific details below.

|  The subsequent 2-bit Res field is reserved; it SHOULD be set to 0
|  by the sending PE and ignored by the receiving PE.
|
|  The next 6 bits provide a length field, which is used as follows:
   [...]

Note: 'SHOULD' is appropriate as future (optional) specifications
      might assign semantics to that field.


(3)  Section 5.4 -- word omission

Section 5.4 (on page 10 of RFC 4717) says:

   The setting of the TTL value in the PW label is application
|  dependent.  In any case, [RFC3032] TTL processing procedure,
   including handling of expired TTLs, MUST be followed.

It should say:

   The setting of the TTL value in the PW label is application
|  dependent.  In any case, the [RFC3032] TTL processing procedure,
   including handling of expired TTLs, MUST be followed.


(4)  Section 6.3 -- word omission

On page 14, Section 6.3 of RFC 4717 contains the numbered item:

|      -iv. The Length of AAL5 frame may exceed the MTU of the PSN.
            This requires fragmentation, which may not be available to
            all nodes at the PW endpoint.

The RFC should say:

|      -iv. The Length of an AAL5 frame may exceed the MTU of the PSN.
            This requires fragmentation, which may not be available to
            all nodes at the PW endpoint.


(5)  Section 7.4 -- distorting typo

The initial text of Section 7.4 (on page 17 of RFC 4717) contains
the line:

|    - (b) On the ATM side of the PW
                                  ^^
This is misleading.  It certainly should say:

|    - (b) On the ATM side of the PE
                                  ^^

(6)  Section 8 -- misleading short text / lack of precision

Section 8 of RFC 4717 (on page 18) says:

   The N-to-one mode (N >= 1) described in this document allows a
   service provider to offer an ATM PVC- or SVC-based service across a
   network.  The encapsulation allows multiple ATM VCCs or VPCs to be
   carried within a single PSN tunnel.  A service provider may also use
   N-to-one mode to provision either one VCC or one VPC on a tunnel.
   This section defines the VCC and VPC cell relay services over a PSN
   and their applicability.

For clarity and added precision, it should say:

   The N-to-one mode (N >= 1) described in this document allows a
   service provider to offer an ATM PVC- or SVC-based service across a
|  packet switched network.  The encapsulation allows multiple ATM VCCs
   or VPCs to be carried within a single PSN tunnel.  A service provider
   may also use N-to-one mode to provision either one VCC or one VPC on
   a tunnel.  This section defines the VCC and VPC cell relay services
   over a PSN and their applicability.


(7)  Section 8.1 -- various clarifications

(7a)  missing applicability statement for PW Types -- also (1c) above

The initial paragraph of Section 8.1 (on page 19 of RFC 4717) says:

   This section describes the general encapsulation format for ATM over
   PSN pseudowires.

According to the expanations in item (1) above, it should say:

   This section describes the general encapsulation format for ATM over
|  PSN pseudowires used with the MPLS PW types 0x0009 and 0x000A (for
|  VCC and VPC transport, respectively) described in Section 5.1.2.

Note: As could be seen later, after the publication of RFC 4816,
this format is reused there.  Thus, it might be even better to say:

   This section describes the general encapsulation format for ATM over
|  PSN pseudowires used with the MPLS PW types 0x0009 and 0x000A (for
|  VCC and VPC transport, respectively) described in Section 5.1.2,
|  and PW Type 0x0003 (transparent cell transport [RFC-to-be-4816]).

Accordingly, an Informative Reference to the work-in-progress
predecessor of RFC 4816 would have to be added to Section 18.

(7b)  inprecise wording not reflecting requirements language elsewhere

In Section 8.1, the 3rd paragraph below Figure 4 (on mid-page 19)
says:

|  As shown above, in Figure 4, the ATM Control Word is inserted before
|  the ATM service payload.  It may contain a length field and a
   sequence number field in addition to certain control bits needed to
   carry the service.

Taken literally, this text is misleading and partially contradicts
the requirements specified in Section 5.1 (in the second paragraph
on page 7).  In particular, the entire ATM control word (the 3rd word
in Figure 4) is optional, and *not* the various bit fields therein.
To properly reflect these requirements, the RFC should says instead:

|  As shown above, in Figure 4, the optional ATM Control Word (if
|  present) is inserted before the ATM service payload. It contains a
   length field and a sequence number field in addition to certain
   control bits needed to carry the service.

(7c)  bad grammar

Within Section 8.1, the last paragraph on page 20 says:

     * When multiple VCCs or VPCs are transported in one pseudowire,
       VPI/VCI values MUST be unique.  When the multiple VCCs or VPCs
|      are from different a physical transmission path, it may be
                         ^^^                          ^
       necessary to assign unique VPI/VCI values to the ATM connections.
       If they are from the same physical transmission path, the VPI/VCI
       values are unique.

It should say:

     * When multiple VCCs or VPCs are transported in one pseudowire,
       VPI/VCI values MUST be unique.  When the multiple VCCs or VPCs
|      are from different physical transmission paths, it may be
                         ^                          ^^
       necessary to assign unique VPI/VCI values to the ATM connections.
       If they are from the same physical transmission path, the VPI/VCI
       values are unique.

(7d)  Improper use of RFC 2119 keywords

According to RFC 2119, 'MUST' requirements do not admit exceptions.
If exceptional behavior is to be admitted via 'MAY' clauses, the
generally preferred behavior must be specified with 'SHOULD'.

Thus in the light of the explanation at the bottom of page 20
-- quoted and clarified above in (7c) --, the two bullets on top
of page 21,

     * VPI

|      The ingress router MUST copy the VPI field from the incoming cell
       into this field.  For particular emulated VCs, the egress router
       MAY generate a new VPI and ignore the VPI contained in this
       field.

     * VCI

|      The ingress router MUST copy the VCI field from the incoming ATM
       cell header into this field.  For particular emulated VCs, the
       egress router MAY generate a new VCI.

should say:

     * VPI

|      The ingress router SHOULD copy the VPI field from the incoming
       cell into this field.  For particular emulated VCs, the egress
       router MAY generate a new VPI and ignore the VPI contained in
       this field.

     * VCI

|      The ingress router SHOULD copy the VCI field from the incoming
       ATM cell header into this field.  For particular emulated VCs,
       the egress router MAY generate a new VCI.


(8)  Sections 9.3 ff. -- alignment flaws in artwork

(8a)
Within Section 9.3, the top part of Figure 8 on page 24 contains
a misaligned border;

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               PSN Transport Header (As Required)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |                      Pseudowire Header                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | [...]

should be:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               PSN Transport Header (As Required)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |                      Pseudowire Header                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | [...]

The same flaw recurs ...

(8b)  within Section 9.4.1, in Figure 9 on page 25;
(8c)  within Section 9.4.1, in Figure 10 on page 26;
(8d)  within Section 11.1, in Figure 12 on page 29;


(9)  Section 9.4.1 -- word omission

On mid-page 25, the bullet,

     * VCI Bits

|      The 16-bit Virtual Circuit Identifier (VCI) incorporates ATM
       Layer VCI value of the cell.

should say:

     * VCI Bits

|      The 16-bit Virtual Circuit Identifier (VCI) incorporates the ATM
       Layer VCI value of the cell.


(10)  Section 10.1 -- multiple mis-specifications

(10a)
As will be explained below, the initial part of Section 10.1
(on page 27) comprises several issues.

The RFC says:

|  The AAL5 CPCS-SDU is prepended by the following header:

    0                   1                   2                   3
    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 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |  Res  |T|E|C|U|Res|  Length   |   Sequence Number (Optional)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              "                                |
   |                     ATM cell or AAL5 CPCS-SDU                 |
   |                              "                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 11: AAL5 CPCS-SDU Encapsulation

It should say:

|  The AAL5 CPCS-SDU or OAM cell is prepended the ATM Control Word:

    0                   1                   2                   3
    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 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |0 0 0 0|T|E|C|U|Res|  Length   |     Sequence Number (or 0)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|    Figure 11: Control Word used with AAL5 CPCS-SDU Encapsulation

Rationale:

(a.1)
The text is wrong and misleading; the figure does not (merely) show
'the prepended header' (i.e., the "ATM Control Word", according to
other parts of this RFC), but the payload as well!
The top level structure of the encapsulation is specified in Figure 4;
hence, it suffices to specify the details of the Control Word here.
Accordingly, the above replacement omits the payload and presents
a modified figure caption.

(a.2)
The 4 most significant bits of the ATM Control Word MUST be all zero.
Denoting the field as 'reserved' is misleading; future specifications
MUST NOT change the value.  See Section 5.1.2 of this RFC, RFC 4385,
and the recently published RFC 4928 for additional explanation!

(a.3)
The 'Sequence Number' field is *not* optional in the control word,
as erroneously might be deduced from the original version of the
figure; it MUST always be present; according to Section 5.1.2, only
the *processing* of this field is optional, and the reserved value 0
is *not* a valid sequence number; it indicates non-use of sequence
number processing.  Hence, the lower half of the ATM Control Word
either contains a sequence number or 0.

(10b)
The T bit explanation (in the lower half of page 27) contains
misleading and inappropriate wording related to Figure 4.
Figure 4 generally applies for both the proper AAL5 CPCS-SDU payload
or the case of an ATM OAM cell payload.  Furthermore, it should be
noted that Section 8.1 (which contains and explains Figure 4)
specifies the Flags field as 'reserved, should be set to 0'.
This is incompatible with the subsequent text that requires the T bit
to be set to 1 for an OAM cell.  Therefore, to avoid confusion,
the clause referencing to Figure 4 should better be deleted from
the T bit explanation.

Hence, the text,

       Bit (T) of the control word indicates whether the packet contains
       an ATM admin cell or an AAL5 payload.  If T = 1, the packet
|      contains an ATM admin cell, encapsulated according to the N-to-
|      one cell relay encapsulation, Figure 4.  If not set, the PDU
       contains an AAL5 payload.  The ability to transport an ATM cell
       in the AAL5 SDU mode is intended to provide a means of enabling
       administrative functionality over the AAL5 VCC (though it does
       not endeavor to preserve user-cell and admin-cell
       arrival/transport ordering).

should say:

       Bit (T) of the control word indicates whether the packet contains
       an ATM admin cell or an AAL5 payload.  If T = 1, the packet
|      contains an ATM admin cell.  If T = 0, the PDU contains an AAL5
       payload.  The ability to transport an ATM cell in the AAL5 SDU
       mode is intended to provide a means of enabling administrative
       functionality over the AAL5 VCC (though it does not endeavor to
       preserve user-cell and admin-cell arrival/transport ordering).

(10c)  incomplete specification

The description of the fields in Figure 11 is incomplete.
As a service to the reader, for completeness the following
text should be added at the end of Section 10.1:

|  For a description of the Length and Sequence Number fields, see
|  Section 5.1.2.


(11)  Section 11.1 -- surprising/confusing specification details

(11a)  danger of confusion - or a mis-specification?

The placement of the U and E bits in the Control Word shown in
Figure 12 (on page 29) comes to surprise.

Apparently, the two bits are exchanged relatively to their placement
within the PTI field in the Control Word shown in Figure 10
(on page 26).

If this has been done intentionally, it might surprise some
implementors, leading to interoperability problems.
In this case, a specific warning should have been added to the
RFC text in Section 11.1, somewhere below Figure 12, e.g.:

|  Warning to implementors: The order of the E and U bit is reversed
|  relative to their placement in the PTI field of the ATM cell header.
|  Section 11.2.2 below details the bit manipulations to be done by
|  the receiving PE.

But if this is an unintentional oversight, the Control Word part
of Figure 12,

                                                            [...]  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |0 0 0 0| Resvd |   Optional Sequence Number    |M|V| Res |U|E|C|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | [...]

should be corrected to say:

                                                            [...]  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |0 0 0 0| Resvd |   Optional Sequence Number    |M|V| Res |E|U|C|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | [...]
                                                              ^ ^
Note:
  In this case, the procedures laid out in Section 11.2.2
  could easily be collapsed to a simple bit field transfer!

(11b)  lack of precision

Below Figure 12, the RFC text on page 29 says:

   The M, V, Res, and C bits are as defined earlier for VCC One-to-one
   cell mode.

For clarity and completeness, it should say:

   The M, V, Res, and C bits are as defined earlier for VCC One-to-one
|  cell mode.  M must be set to 1 and V must be set to 0 for AAL5 PDU
|  Encapsulation; further details regarding the C bit are given below.


(12)  Section 11.2.1 -- internal mis-ref.

The 3rd bullet in Section 11.2.1, near the bottom of page 30, says:

     - The E and C bits of the fragment shall be set as defined in
|      section 9.
               ^
It should say:

     - The E and C bits of the fragment shall be set as defined in
|      section 11.1.
               ^^^^

Rationale:
  As explained above for item (11a), the specification of these bits in
  Section 11.1 is contrary to their (hidden) use in Sections 8 and 9.


(13)  Section 11.2.2 -- significant typo (wrong bit field name)

Section 11.2.2 (on page 31) contains the bullet:

      -iii. The least significant bit for the last ATM cell in the PSN
|           frame is set to the value of the UU bit of Figure 12.
                                             ^^
It should say:

      -iii. The least significant bit for the last ATM cell in the PSN
|           frame is set to the value of the U bit of Figure 12.
                                             ^

(14)  Section 12 -- internal mis-refs

The last paragraph of Section 12 (on page 32) says:

   In both the ATM-to-PSN and PSN-to-ATM directions, the method used to
   transfer the CLP and EFCI information of the individual cells into
   the ATM-specific field, or flags, of the PW packet is described in
|  detail in sections 6 through 9 for each encapsulation mode.
                      ^         ^
It should say:

   In both the ATM-to-PSN and PSN-to-ATM directions, the method used to
   transfer the CLP and EFCI information of the individual cells into
   the ATM-specific field, or flags, of the PW packet is described in
|  detail in sections 8 through 11 for each encapsulation mode.
                      ^         ^^

(15)  Abuse of language

'AAL5' stands for "ATM Adaptation Layer 5".  Hence, the wording
"ATM AAL5" is a replication considered a rough abuse of language.

All occurrences of "ATM AAL5" in the RFC should be corrected to "AAL5".

Notes:


--VERIFIER NOTES--
This complex, multi-part, erratum has been split into a number of errata to make it easier for the reader to determine the resolution of the components. Some components have been verified, some rejected and some deferred. To guard against an editing error I am leaving 999 itself untouched, but in rejected state lest it is necessary to inspect the original erratum text.

The reader is revered to the other errata raised against RFC4717 to determine the resolution of each element of this errata.

Errata ID: 2919

Status: Rejected
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2007-10-17
Rejected by: Stewart Bryant
Date Rejected: 2011-08-05

 



(7d)  Improper use of RFC 2119 keywords

According to RFC 2119, 'MUST' requirements do not admit exceptions.
If exceptional behavior is to be admitted via 'MAY' clauses, the
generally preferred behavior must be specified with 'SHOULD'.

Thus in the light of the explanation at the bottom of page 20
-- quoted and clarified above in (7c) --, the two bullets on top
of page 21,

     * VPI

|      The ingress router MUST copy the VPI field from the incoming cell
       into this field.  For particular emulated VCs, the egress router
       MAY generate a new VPI and ignore the VPI contained in this
       field.

     * VCI

|      The ingress router MUST copy the VCI field from the incoming ATM
       cell header into this field.  For particular emulated VCs, the
       egress router MAY generate a new VCI.

should say:

     * VPI

|      The ingress router SHOULD copy the VPI field from the incoming
       cell into this field.  For particular emulated VCs, the egress
       router MAY generate a new VPI and ignore the VPI contained in
       this field.

     * VCI

|      The ingress router SHOULD copy the VCI field from the incoming
       ATM cell header into this field.  For particular emulated VCs,
       the egress router MAY generate a new VCI.



Notes:

This is section 7(d) From erratum 999
--VERIFIER NOTES--
The MUST and the MAY refer to the behavior of different PW entities (ingress and egress router respectively), thus the original text is correct.

Errata ID: 2918

Status: Rejected
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2007-10-17
Rejected by: Stewart Bryant
Date Rejected: 2011-08-05

 

(1)  incomplete/missing specification of PW types

RFC 4446 (by means of reference update from drafts to published RFCs)
and the IANA "pwe3-parameters" registry refer to this document for
the allocation and description of a couple of (MPLS) Pseudowire Types.
Therefore, this memo should be explicit, precisely give the proper
information, and not leave the reader alone with some apparent
ambiguities in the registry.  (Unfortunately, the RFC uses
descriptive text labels for the PW types that do not match the
text listed as the 'Descriptions' in the MPLS PW Type registry.)

Excluding the PW type 0x001E assigned for the MFA, IANA lists seven
ATM PW types.  I (hopefully) was able to identify most of these in
RFC 4717, but the role of PW type 0x0003 initially remained unclear;
this gap in the meantime has been closed by RFC 4816, taking over
the 'ownership' for that PW type.

To fill in the gap, the following clarifications should be posted
in an RFC errata note for RFC 4717 (please correct if I'm wrong);
because there also is a L2TPv3 Pseudowire Type (sub-)registry
(in the IANA "l2tp-parameters" registry) I also use the precise
term, "MPLS PW Type", in the proposed clarifications.

(1a)  Section 5.1.1

The initial text of Section 5.1.1 (on page 7 of RFC 4717) says:

   This control word is used in the following encapsulation modes:

     - ATM One-to-one Cell Mode
     - AAL5 PDU Frame Mode

It should say:

   This control word is used in the following encapsulation modes:

|    - ATM One-to-one Cell Mode  - MPLS PW types 0x000C and 0x000D
|    - AAL5 PDU Frame Mode       - MPLS PW type 0x000E

(1b)  Section 5.1.2

The initial text of Section 5.1.2 (on page 8 of RFC 4717) says:

   This control word is used in the following encapsulation modes:

     - ATM N-to-one Cell Mode
     - AAL5 SDU Frame Mode

It should say:

   This control word is used in the following encapsulation modes:

|    - ATM N-to-one Cell Mode  - MPLS PW types 0x0009 and 0x000A
|    - AAL5 SDU Frame Mode     - MPLS PW type 0x0002

(1c)  see item (6a) below!

(1d)  missing IANA Considerations

NOTE:
  Would the above clarifications have been included in the RFC,
  it should also have contained an IANA Considerations Section.
  In the meantime, after some complaints and interventions, the
  IANA "pwe3-parameters" registry has been updated to contain the
  proper pointers to RFC 4717 for the abovementioned six PW Types.

======

(7a)  missing applicability statement for PW Types -- also (1c) above

The initial paragraph of Section 8.1 (on page 19 of RFC 4717) says:

   This section describes the general encapsulation format for ATM over
   PSN pseudowires.

According to the expanations in item (1) above, it should say:

   This section describes the general encapsulation format for ATM over
|  PSN pseudowires used with the MPLS PW types 0x0009 and 0x000A (for
|  VCC and VPC transport, respectively) described in Section 5.1.2.

Note: As could be seen later, after the publication of RFC 4816,
this format is reused there.  Thus, it might be even better to say:

   This section describes the general encapsulation format for ATM over
|  PSN pseudowires used with the MPLS PW types 0x0009 and 0x000A (for
|  VCC and VPC transport, respectively) described in Section 5.1.2,
|  and PW Type 0x0003 (transparent cell transport [RFC-to-be-4816]).

Accordingly, an Informative Reference to the work-in-progress
predecessor of RFC 4816 would have to be added to Section 18.


======





Notes:

This was section 1 and section 7(a) of Errata 999
--VERIFIER NOTES--
The ATM PW Encapsulation modes specified are used by multiple ATM PW types and the intent of the working group was to allow new ATM PW types to use these encapsulations without requiring an update or republication of RFC 4717

Errata ID: 2921

Status: Rejected
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2007-10-17
Rejected by: Stewart Bryant
Date Rejected: 2012-02-21

 



(11a)  danger of confusion - or a mis-specification?

The placement of the U and E bits in the Control Word shown in
Figure 12 (on page 29) comes to surprise.

Apparently, the two bits are exchanged relatively to their placement
within the PTI field in the Control Word shown in Figure 10
(on page 26).

If this has been done intentionally, it might surprise some
implementors, leading to interoperability problems.
In this case, a specific warning should have been added to the
RFC text in Section 11.1, somewhere below Figure 12, e.g.:

|  Warning to implementors: The order of the E and U bit is reversed
|  relative to their placement in the PTI field of the ATM cell header.
|  Section 11.2.2 below details the bit manipulations to be done by
|  the receiving PE.

But if this is an unintentional oversight, the Control Word part
of Figure 12,

                                                            [...]  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |0 0 0 0| Resvd |   Optional Sequence Number    |M|V| Res |U|E|C|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | [...]

should be corrected to say:

                                                            [...]  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |0 0 0 0| Resvd |   Optional Sequence Number    |M|V| Res |E|U|C|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | [...]
                                                              ^ ^
Note:
  In this case, the procedures laid out in Section 11.2.2
  could easily be collapsed to a simple bit field transfer!


Notes:

This is element 11(a) of Errata 999

This needs to checked against the corresponding ITU specification for this mode.
--VERIFIER NOTES--
RFC4717 and ITU-T Recommendation Y.1412 use the same bit definitions and the same bit ordering, and therefore one must conclude that the bit ordering was that which was intended by the authors and has thus implemented.

There have been no concerns expressed on the PWE3 list regarding the change of ordering between Figure 11 and Figure 12.

Report New Errata