Subject: PW status TLV Problem.

From: Luca Martini <[email-masked]>
Date: Fri, 06 Feb 2004 19:30:14 -0700

WG,

I received several e-mail pointing out that section 5.3. "Signaling of 
Pseudo Wire Status" is flawed.
In rfc3036 the notification message in section 3.5.1 page 47 does not 
states clearly that the status TLV is mandatory. But After speaking with 
some of the authors it appears that the status TLV is mandatory.
In the definition of the Pw status procedures section 5.3.2 I replaced 
the status TLV with a PW status TLV. This violates RFC3036.
In section 5.3.3. "Pseudowire Status Negotiation Procedures" there is a 
statement that requires the PW status TLV to appear immediately after 
the PW FEC. However, the Label mapping TLV must appear immediately after 
the PW FEC.

I would like to suggest a simple fix to this problem along these lines:

- define the PW status TLV as an optional parameter for the notification 
message.
- obtain a new status code "PW status message" next available code would 
be 0x00000028
- define the PW status TLV and relevant FEC in the optional parameter 
field.

Here is the relevant text:

5.3. Signaling of Pseudo Wire Status

5.3.1. Use of Label Mappings.

   The PEs MUST send PW label mapping messages to their peers as soon as
   the PW is configured and administratively enabled, regardless of the
   CE-facing interface state. The PW label should not be withdrawn
   unless the user administratively configures the CE-facing interface
   down (or the PW configuration is deleted entirely). A simple label
   withdraw method MAY also be supported as an alternative. In any case
   if the Label mapping is not available the PW MUST be considered in

Martini, et al.                                                [Page 16]
^L
Internet Draft  draft-ietf-pwe3-control-protocol-05.txt    December 2003

   the down state.

5.3.2. Signaling PW status.

   The PE devices use an LDP TLV to indicate status to their remote
   peers. This PW Status TLV contains more information than the
   alternative simple Label Withdraw message.

   The format of the PW Status TLV is:
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|     PW Status (0x096A)    |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Status Code                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   [ note: TLV type 0x096A as defined in [13] pending IANA allocation ]

   Where the status code is a 4 octet bit field is specified in the PW
   IANA Allocations document [13].

   Each bit in the status code field can be set individually to indicate
   more then a single failure at once. Each fault can be cleared by
   sending an appropriate status message with the respective bit
   cleared. The presence of the lowest bit (PW Not Forwarding) acts only
   as a generic failure indication when there is a link-down event for
   which none of the other bits apply.

   The Status TLV is transported to the remote PW peer via the LDP
   notification message. The general format of the Notification Message
   is:

    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)                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Optional Parameters                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Status TLV status code is set to 0x00000028 "PW status", to

Martini, et al.                                                [Page 17]
^L
Internet Draft  draft-ietf-pwe3-control-protocol-05.txt    December 2003

   indicate that PW status follows. Since this notification does not
   refer to any particular message the Message Id, and Message Type
   fields are set to 0.

   [ note: Status Code 0x00000028 as defined in [13] pending IANA
   allocation ]

   The PW FEC TLV SHOULD not include the interface parameters as they
   are ignored in the context of this message. When a PE's CE-facing
   interface encounters an error, use of the PW status message allows
   the PE to send a single status message, using a PW FEC TLV with only
   the group ID set, to denote this change in status for all affected PW
   connections.

   As mentioned above the Group ID field can be used to send a status
   notification for all PWs associated with a particular group ID. This
   procedure is OPTIONAL, and if it is implemented the LDP Notification
   message should be as follows: the PW information length field is set
   to 0, the PW ID field is not present, and the interface parameters
   field is not present. For the purpose of this document this is called
   the "wild card PW status notification procedure", and all PEs
   implementing this design are REQUIRED to accept such a notification
   message, but are not required to send it.

5.3.3. Pseudowire Status Negotiation Procedures

   When a PW is first set up the PEs MUST attempt to negotiate the usage
   of the PW status TLV. This is accomplished as follows:

   A PE that supports the PW Status TLV MUST include it the initial
   label mapping signaling immediately following the PW FEC and the
   interface parameters field. The PW Status TLV will be used for the
   lifetime of the Pseudowire for PEs that support this TLV.

   If the PW Status TLV is not present immediately following the initial
   PW FEC Message received by a PE, then the PW Status TLV will not be
   used and both PEs supporting the pseudowire will revert to the label
   withdraw procedure for signaling status changes.

   If PW status TLV is sent immediately following the label mapping TLV
   in the initial PW FEC Message, but the remote PE corresponding FEC
   advertisement does not include a PW status TLV, or the remote PE does
   not support the PW Status TLV then the PW will revert to the label
   withdraw method to signal PW status. Note that if the PW Status TLV
   is not supported it will automatically be ignored since the LDP
   ignore bit is set.

Martini, et al.                                                [Page 18]
^L
Internet Draft  draft-ietf-pwe3-control-protocol-05.txt    December 2003

   If the negotiation process results in the usage of the PW status TLV,
   then the actual PW status is determined by the PW status TLV that was
   sent within the initial PW label mapping. Subsequent updates of PW
   status are conveyed through the notification message

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                 PWId FEC or Generalized ID FEC                +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Interface parameters                    |
   |                              "                                |
   |                              "                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|     PW Status (0x0???)    |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Status Code                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-------------------------------------------------------------------------------------------------------------------------------------------

I also added the following :

11. Appendix B - Notification Message   PW Status Diagram

    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                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|1| Status (0x0300)           |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|1|                 Status Code=0x00000028                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID=0                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Message Type=0           |      PW Status TLV            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         PW Status TLV                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         PW Status TLV         |            PWId FEC           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   |                 PWId FEC or Generalized ID FEC                |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Please send me comments on this text ..... ( last time nobody caught the 
problem in the last call ! )
After discussing this with the WG chairs we would like to reissue a last 
call for this section only.

In lieu of some very good discussion in the RIFT draft does anybody 
thing that it might not be a bad idea to create a completely new message 
type ? this would avoid any interference between code that deals with 
the LDP session itself , and PW FEC which is a payload of the LDP session.

Comments ?

Thanks.
Luca

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 11 Feb 2004 14:27:20 -0500

Comments in line marked as HS>

> -----Original Message-----
> From: Luca Martini [mailto:[email-masked]]
> Sent: Friday, February 06, 2004 9:30 PM
> To: [email-masked]
> Subject: [PWE3] PW status TLV Problem.
> 
> 
> WG,
> 
> Martini, et al.                                               
>  [Page 16]
> Martini, et al.                                               
>  [Page 17]

HS> There might be room for confusion here in terms of how one should handle
HS> wild card PW status in conjunction with pre-existing individual PW status
HS> and vice-versa. I would suppose PE should continue to practice individual
HS> fault clearing when they are non-overlapping. If it is true, sender must
HS> still keep a record of what faults has been cleared on individual PW basis
HS> even when individual and group status messages are used inter-mixedly.

>    lifetime of the Pseudowire for PEs that support this TLV.

HS> The above paragraph should be reworded to be more clearer that
HS> PW STATUS TLV follows the Label TLV and not "immediately" following
HS> the PW FEC. So the order is - PW-FEC TLV, Label TLV, PW Status TLV.
HS> It does mention this in the following paragraphs, but that is after
HS> it has been mentioned twice that it should "immediately follow PW-FEC".

> Martini, et al.                                               
>  [Page 18]

HS> Note that above figure is misleading too. You should include 
HS> Label TLV before PW Status TLV and the status type as (0x096A)
HS> as shown earlier.

> --------------------------------------------------------------
> --------------------------------------------------------------
> ---------------
> 

HS> I would prefer to keep 16-bit field after message type as reserved
HS> and start the PW-STATUS TLV on 4-byte boundary so the STATUS code
HS> is not split on 2 16-bit words and so is PW-ID FEC information.

> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Luca Martini <[email-masked]>
Date: Wed, 11 Feb 2004 16:37:32 -0700

Himanshu,

In general I seem to have issues with the pictures and some text.  I 
fixed all these problems , and will post the new version shortly.

more comments in line.

Thanks.
Luca

>>   The format of the PW Status TLV is:

I fixed this diagram as well.

>HS> even when individual and group status messages are used inter-mixedly.
yes this is correct. This problem is similar to the wildcard withdraw/release procedure defined in rfc3036. I'm not inventing anything new here. presumably the group id is saved along with the rest of the PW information. Wildcard status messages will then be applied to all PWs matching the group id in the status message.

>HS> it has been mentioned twice that it should "immediately follow PW-FEC".
yes , fixed.

>HS> is not split on 2 16-bit words and so is PW-ID FEC information.
i'm not sure that being 32-bit word  aligned was a design parameter in 
LDP. I'll ask Bob Thomas about it.
( there are lot's of instances where LDP is not word aligned. )