Subject: [PWE3] PWE3 Errata 938

From: Stewart Bryant <[email-masked]>
Date: Mon, 19 Sep 2011 11:45:23 +0100

Here is how I suggest that we address Errata 938

http://www.rfc-editor.org/errata_search.php?eid=938

Please look for "SB>"

I would like WG input on the proposed resolution.

Please treat this as a two week last call, which will
end on 3rd October.

- Stewart

============

Errata ID: 938

*Status: Reported
Type: Technical
*
Reported By: Alfred Hoenes
Date Reported: 2006-11-09

(1) [[posted separately.]]

SB>  Nothing to do

(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

SB>  Classify as Editorial - hold for document update

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

SB>  Classify as Editorial - hold for document update
  
(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

SB>  Classify as Editorial  - hold for document update
  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.

SB>  Classify as Editorial - hold for document update

(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

SB>  Classify as Editorial - hold for document update

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

SB>  Classify as Editorial - hold for document update

(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

SB>  The grouping ID is optional, so we could either reject the
SB>  proposed change, or accept with the last item as
SB>  "Optional PW Grouping ID TLV"
SB>  In any case I propose to reclassify as Editorial, - hold for
SB>  document update

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

SB>Re-classify as editorial - hold for document update

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

SB>Re-classify as editorial - hold for document update

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

SB>Re-classify as editorial - hold for document update

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.

SB>Re-classify as editorial - hold for document update

---

From: Luca Martini <[email-masked]>
Date: Mon, 19 Sep 2011 19:05:33 -0600

> Please treat this as a two week last call, which will
I would say to reject this .
The table is meant as a quick index to find information about a specific
FEC.
In any revisions this table would simply be removed.

> SB>  Classify as Editorial - hold for document update
please reject .
What is written is exactly what was intended.
A group id is not part of a virtual tunnel, a set of PWs , or PW IDs can
be part of a virtual tunnel and hence you can assign the group ID to it.
There is ever only one group ID per PW.
The original text is a bit brief, but correct.

> SB>  Classify as Editorial  - hold for document update
Reject.
Terminology was correct at the time.

> SB>  Classify as Editorial - hold for document update
I do not see how his version is any better.
In fact it is incorrect.
 The "Specified" means the particular grouping ID specified in the
message , not where it is specified.
 
Reject.

> SB>  Classify as Editorial - hold for document update
same as above , in the document we never put ID in the titles.
Reject.

> SB>  Classify as Editorial - hold for document update
again - terminology was correct
Reject.
> message diagram in Section 5.4.2, at the bottom of page 17,
Reject.
This diagram should not be cluttered with unnecessary information.

> SB>Re-classify as editorial - hold for document update
Reject.
Again terminology was correct for the time.
> SB>Re-classify as editorial - hold for document update
Accept - editorial..

> SB>Re-classify as editorial - hold for document update
same comment - reject - terminology was correct.

> SB>Re-classify as editorial - hold for document update
reject.
same comment.
it is the generalized PW FEC Element.
Not the "generalized PWid FEC element"

Luca