Subject: Re: PW status TLV Problem.

From: Wei Luo <[email-masked]>
Date: Wed, 11 Feb 2004 14:42:37 -0800

Luca,

Comments inline.

Another thing you may want to consider is to have a signaling procedure for 
implementations that support both FEC 128 and 129 to be able to determine the 
FEC type dynamically instead of through manual configuration.  Some earlier 
revisions of the draft actually have that section.

Luca Martini wrote:

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

What is the rationale to mandate the PW Status TLV be *immediately* following 
the FEC TLV?  In other words, why does the ordering of the TLVs make any difference?

Implementations always parse the entire Label Mapping message, decode TLVs into 
internal binary representations, and then apply appropiate actions.  The 
location of the PW Status TLV inside the Label Mapping message does not seem to 
have any impact on operation.  Unless I miss something obvious, I'd suggest we 
change the text to "the presence of the PW status TLV in the Label Mapping 
message indicates that a PE supports PW Status signaling."

---Wei

> 
>   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
> 
> 
> 
> 
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Luca Martini <[email-masked]>
Date: Wed, 11 Feb 2004 17:15:09 -0700

Wei Luo wrote:

> Luca,
>
> Comments inline.
>
> Another thing you may want to consider is to have a signaling 
> procedure for implementations that support both FEC 128 and 129 to be 
> able to determine the FEC type dynamically instead of through manual 
> configuration.  Some earlier revisions of the draft actually have that 
> section.
>
??? I think that the diagram points out that this applies to all FEC in 
this draft....
what section ?

> What is the rationale to mandate the PW Status TLV be *immediately* 
> following the FEC TLV?  In other words, why does the ordering of the 
> TLVs make any difference?
>
> Implementations always parse the entire Label Mapping message, decode 
> TLVs into internal binary representations, and then apply appropiate 
> actions.  The location of the PW Status TLV inside the Label Mapping 
> message does not seem to have any impact on operation.  Unless I miss 
> something obvious, I'd suggest we change the text to "the presence of 
> the PW status TLV in the Label Mapping message indicates that a PE 
> supports PW Status signaling."
>
this actually comes from rfc3036 where the order is specified. the label 
must immediately follow the FEC etc.
I don't really care where the TLV is , but RFC3036 does.

>> 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.
>>
>> 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: Wei Luo <[email-masked]>
Date: Wed, 11 Feb 2004 16:42:13 -0800

> ??? I think that the diagram points out that this applies to all FEC in 

Sorry, I should have clarified that I was making a comment to the draft in 
general, not this particular section being discussed.  I suggested having a 
section address the compatibility issue of FEC 128 and FEC 129.

> I don't really care where the TLV is , but RFC3036 does.

Could you kindly point me to the text in RFC3036 requiring such an ordering? 
All I found is that the Label Mapping message was drawn in such a way that FEC 
TLV happens to be in front of Label TLV.  Given there is TLV type associated 
with each, I don't see why the order matters.  But that's not the point I am 
trying to make.

Since PW Status TLV could be one of the many optional parameters in the Label 
Mapping Message and the order doesn't seem to be important for the optional 
parameters, I would suggest not making that as a mandate.

---Wei

---

From: Luca Martini <[email-masked]>
Date: Fri, 20 Feb 2004 12:38:48 -0700

3.5.7. Label Mapping Message

Wei Luo wrote:
[snip]

>>>
>> this actually comes from rfc3036 where the order is specified. the 
>> label must immediately follow the FEC etc.
> Could you kindly point me to the text in RFC3036 requiring such an 
> ordering? All I found is that the Label Mapping message was drawn in 
> such a way that FEC TLV happens to be in front of Label TLV.  Given 
> there is TLV type associated with each, I don't see why the order 
> matters.  But that's not the point I am trying to make.

in section "3.5.7. Label Mapping Message" there is a picture indicating 
that the message should look like. This implies that the status TLV 
needs to be in the optional parameter section.

> Since PW Status TLV could be one of the many optional parameters in 
> the Label Mapping Message and the order doesn't seem to be important 
> for the optional parameters, I would suggest not making that as a 
> mandate.
>
ho, now i understand. ( I think ) you mean put the status tlv after the 
label mapping , but not necessarily immediately after it.

Yes , I will make the change.

Luca