Subject: RFC 4447

From: Alfred Hönes <[email-masked]>
Date: Thu, 9 Nov 2006 21:51:18 +0100 (MEZ)

Hello,
after studying RFC 4447 (LDP usage for PWE3) edited/authored
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) General Note:

Unfortunately, RFC 4447 does not precisely, verbatim, and
consistently use names and terms defined in previous
specifications and in the RFC text itself, in (subsequent)
parts of the text.
This makes it difficult for the non-specialist to keep all the
things together.
In particular, the terms/names,
   "Message" or "Message Type",
   "FEC" or "FEC TLV" (a *TLV*)
(as introduced in the basic LDP specification, RFC 3036),
   "PWid FEC Element" and "Generalized PWid FEC Element"
(introduced in Sections 5.2 and 5.3 of RFC 4447, respectively), and
   "PW Grouping ID TLV"
(introduced in Section 5.1 of RFC 4447) are used in a slaggish
manner and varied substantially later on in the text.
I only have caught some of the instances of this issue in the
list below.  Any derived work should make consistent use of the
defined terms and names, in particular in Standards Track documents!

(1)  two typos in the Abstract

The Abstract of RFC 4447 says:

                     [...].  It is also possible to use pseudowires to
   provide low-rate Time Division Multiplexed and a Synchronous Optical
   NETworking circuit emulation over an MPLS-enabled network.  This
   document specifies a protocol for establishing and maintaining the
   pseudowires, using extensions to Label Distribution Protocol (LDP).
   Procedures for encapsulating Layer 2 PDUs are specified in a set of
   companion documents.

It should perhaps better say:

                     [...].  It is also possible to use pseudowires to
   provide low-rate Time Division Multiplexed and Synchronous Optical
|  NETworking circuit emulation over an MPLS-enabled network.  This
   document specifies a protocol for establishing and maintaining the
|  pseudowires, using extensions to the Label Distribution Protocol
   (LDP).  Procedures for encapsulating Layer 2 PDUs are specified in a
   set of companion documents.

(2)  wrong term(s) used in table(s)

Within Section 5.1 of RFC 4447, on page 8, the first 2 tables say:

   This document specifies the following new TLVs to be used with LDP:

   TLV                    Specified in Section     Defined for Message
   ===================================================================
   PW Status TLV                  5.4.2            Notification
   PW Interface Parameters TLV    5.3.2.1          FEC
   PW Grouping  ID TLV            5.3.2.2          FEC

   Additionally, the following new FEC element types are defined:

   FEC Element Type        Specified in Section    Defined for Message
   ===================================================================
   0x80                            5.2             FEC
   0x81                            5.3             FEC

Apparently, "FEC" is not appropriate in the last column of the first
table, and "Defined for Message" makes no sense in the second table,
where only "FEC" appears, as "FEC" is not an LDP message, it is a TLV.
Perhaps, the latter column is dispensable, in favor of a new column
showing the name of the FEC element.

Hence, the text perhaps should better say, e.g.:

   TLV                      Specified in Section   Defined for Message
   ===================================================================
   PW Status TLV                    5.4.2          Notification
|  PW Interface Parameters TLV      5.3.2.1        with FEC TLV
|  PW Grouping ID TLV               5.3.2.2        with FEC TLV

   Additionally, the following new FEC element types are defined:

|  FEC Element Type     FEC Element Name          Specified in Section
   ===================================================================
|  0x80                 PWid                               5.2
|  0x81                 Generalized PWid                   5.3

(3)  clarification ( wrong term ?? )

Section 5.2, at the bottom of page 9, says:

   -  Group ID

      An arbitrary 32-bit value that represents a group of PWs that is
      used to create groups in the PW space.  The group ID is intended
      to be used as a port index, or a virtual tunnel index.  To
      simplify configuration, a particular PW ID at ingress could be
      part of the virtual tunnel for transport to the egress router.

I suspect (but I am not 100% sure) that "PW ID" should in fact be
"PW Group ID", i.e., that this text should say:

   -  Group ID

      An arbitrary 32-bit value that represents a group of PWs that is
      used to create groups in the PW space.  The group ID is intended
      to be used as a port index, or a virtual tunnel index.  To
|     simplify configuration, a particular PW Group ID at ingress could
      be part of the virtual tunnel for transport to the egress router.

Please comment.

(4)  clarifications

a) The title of Section 5.3.2,

 5.3.2.  Encoding the Generalized ID FEC Element

for the sake of consistency should better say:

 5.3.2.  Encoding the Generalized PWid FEC Element

b) Within Section 5.3.2, the 2nd-to-last paragraph on page 13 says:

   The PW information length field contains the length of the SAII,
   TAII, and AGI, combined in octets.  If this value is 0, then it
|  references all PWs using the specified grouping ID.  In this case,
   there are no other FEC element fields (AGI, SAII, etc.) present, nor
   any interface parameters TLVs.

To make the context more clear, it might preferrably be amended to say:

   The PW information length field contains the length of the SAII,
   TAII, and AGI, combined in octets.  If this value is 0, then it
|  references all PWs using the grouping ID (specifed in the PW grouping
|  ID TLV).  In this case, there are no other FEC element fields (AGI,
   SAII, etc.) present, nor any interface parameters TLVs.

(5)  consistency of terms

The headline of Section 5.3.2.2,

 5.3.2.2.  PW Grouping TLV

should better say, for terminological consistency:

 5.3.2.2.  PW Grouping ID TLV

(6)  clarification of term

At the end of Section 5.3.2.2, near the top of page 15, the RFC says:

   To issue a wildcard command (status or withdraw):

|  -  Set the PW Info Length to 0 in the Generalized ID FEC Element.

   -  Send only the PW Grouping ID TLV with the FEC (no AGI/SAII/TAII is
      sent).

The first bullet should be enhanced, making use of the defined terms
verbatim, as follows:

   To issue a wildcard command (status or withdraw):

|  -  Set the PW Info Length to 0 in the Generalized PWid FEC Element.

   -  Send only the PW Grouping ID TLV with the FEC (no AGI/SAII/TAII is
      sent).

(6)  message diagram incomplete

After consideration of the RFC text, I strongly suspect that the
message diagram in Section 5.4.2, at the bottom of page 17,

    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|   Notification (0x0001)     |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Message ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Status (TLV)                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      PW Status TLV                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           PWId FEC TLV or Generalized ID FEC TLV              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

in fact should say:

    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|   Notification (0x0001)     |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Message ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Status (TLV)                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      PW Status TLV                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |      FEC TLV with  PWId or Generalized PWId FEC Element       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |                      PW Grouping ID TLV                       |
|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Rationale:
a) using defined terms verbatim
b) final TLV added: PW Grouping ID TLV

(7)  clarifications, terms and wording

Still in Section 5.4.2, the 2nd and 3rd paragraph on page 18 say:

   The PW FEC TLV SHOULD not include the interface parameter sub-TLVs,
   as they are ignored in the context of this message.  When a PE's
   attachment circuit encounters an error, use of the PW Notification
   Message allows the PE to send a single "wild card" status message,
   using a PW FEC TLV with only the group ID set, to denote this change
   in status for all affected PW connections.  This status message
   contains either the PW FEC TLV with only the group ID set, or else it
   contains the Generalized FEC TLV with only the PW Grouping ID TLV.

   As mentioned above, the Group ID field of the PWid FEC element, or
   the PW Grouping ID TLV used with the Generalized ID FEC element, can
   be used to send a status notification for all arbitrary sets of PWs.
   [...]

This text should better say:

|  The PWid FEC element SHOULD NOT include the interface parameter
   sub-TLVs, as they are ignored in the context of this message.  When
   a PE's attachment circuit encounters an error, use of the PW
   Notification Message allows the PE to send a single "wild card"
|  status message, using a PWid FEC element with only the group ID set,
   to denote this change in status for all affected PW connections.
|  This status message contains either a FEC TLV with a PWid FEC element
|  with only the group ID set, or else it contains a FEC TLV with a
|  Generalized PWid FEC element together with only the PW Grouping ID
   TLV.

   As mentioned above, the Group ID field of the PWid FEC element, or
|  the PW Grouping ID TLV used with the Generalized PWid FEC element,
   can be used to send a status notification for all arbitrary sets of
   PWs.
   [...]

(8)  typo (spurious word)

The second-to-last paragraph of Section 6.2, on page 22, says:

                          [...].  If one endpoint prefers to use the
   control word but the other does not, the one that prefers not to use
|  it is has no extra protocol to execute; it just waits for a Label
   Mapping message that has c=0.

It should say:

                          [...].  If one endpoint prefers to use the
   control word but the other does not, the one that prefers not to use
|  it has no extra protocol to execute; it just waits for a Label
   Mapping message that has c=0.

(9)  terminology

a) The first paragraph of Section 6.3, on page 22, says:

   As mentioned above, the Group ID field of the PWid FEC element, or
   the PW Grouping ID TLV used with the Generalized ID FEC element, can
   be used to withdraw all PW labels associated with a particular PW
   group.  [...]

It should say:

   As mentioned above, the Group ID field of the PWid FEC element, or
|  the PW Grouping ID TLV used with the Generalized PWid FEC element,
   can be used to withdraw all PW labels associated with a particular PW
   group.  [...]

b) The second paragraph of Section 6.3, on top of page 23, says:

   If the Generalized FEC element is used, the AGI, SAII, and TAII are
   not present, the PW information length field is set to 0, the PW
   Grouping ID TLV is included, the Interface Parameters TLV is not
   present, and the Label TLV is not present.  For the purpose of this
   document, this is called the "wild card withdraw procedure", and all
   PEs implementing this design are REQUIRED to accept such withdrawn
   message but are not required to send it.  Note that the PW Grouping
   ID TLV only applies to PWs using the Generalized ID FEC element,
   while the Group ID only applies to PWid FEC element.

It should say:

|  If the Generalized PWid FEC element is used, the AGI, SAII, and TAII
   are not present, the PW information length field is set to 0, the PW
   Grouping ID TLV is included, the Interface Parameters TLV is not
   present, and the Label TLV is not present.  For the purpose of this
   document, this is called the "wild card withdraw procedure", and all
   PEs implementing this design are REQUIRED to accept such withdrawn
   message but are not required to send it.  Note that the PW Grouping
|  ID TLV only applies to PWs using the Generalized PWid FEC element,
   while the Group ID only applies to PWid FEC element.

Please comment.

All but item (0) seems to be appropriate for an Errata Note.

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.  But if you like, I can formally
submit an Errata Note on my own, with your consent.

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