Subject: Status signaling in draft-ietf-pwe3-control-protocol-03.txt

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Thu, 3 Jul 2003 15:22:16 -0400

Comments on section 5.3 Status Signaling added
to the new revised version of the control draft.

It looks to me some of the issues that were raised before in the mailing
list were ignored...Here are some items observed on the added
text:

a) There is no mechanism (implicit/explicit) by which a PE will find
   out what is the capability/intent of the remote PE (whether it supports
   status TLV or not).

b) There is no mechanism by which a PE can find out initially what
   is the status of PW during PW setup phase. Upon receiving a label
mapping, 
   the PE assumes the PW is up and starts accepting and sending traffic that

   will end up being discarded if the remote end is down. And that happens
   even if both PEs support status signaling. One may wonder what is
   then the value of status signaling if it can't stop a remote PE from
   sending traffic.

c) Ambiguity for the encoding for both the basic LDP notification and
   status TLV (see below).

d) The proposal seems not backward compatible with
   existing PW behavior and that needs to be explicitly captured in
   the draft. And there is no mechanism that enforces the rule requiring
   both PEs to support status signaling in order for the proposal to work.

See other comments below (on the added 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
   the down state."

Hamid> The question is what is the behavior of the remote end that doesn't
       support status signaling? For the *PW* to be in down state the
       *two* sides of the PW should not forward customer traffic.
      
       Even if we assume that there is a rule that says "A notification
message
       MUST always be sent after the label mapping message" which in the
       text there is none. That does not prevent the above problem from
       happening, and the provider will perform billing/accounting for
traffic
       that will end up being discarded at the remote PE.
      
       And if this rule is applied this proposal forces all PWs to send
       notification messages to all PEs that do not support status
signaling.

     If another rule indicates that a PE should not accept initially
     traffic until positive notification is received, then the problem
     that can happen is a deadlock situation.

.....

more on the text:

"The 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                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             PW FEC TLV  or Generalized ID FEC Element         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         PW Status TLV                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+"

Hamid> If we  reconstruct the complete message for PWid FEC,
       we obtain the following:

    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                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    PW tlv     |C|         PW type             |PW info Length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Group ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           PW ID                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|     PW Status (0x0???)    |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Status Code                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(No parameters are carried as suggested). 

Basic LDP the notification message looks like:

    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                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F| Status (0x0300)           |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Status Code                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Message Type             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>From that I conclude that:

a) A PE cannot distinguish between PE Status signaling and basic
   LDP status signaling. This is ambiguity (even in parsing the
   message). I do not expect this is acceptable.

b) All LDP notification messages must carry PW Status information.
   I do not expect this is acceptable either.

In the text as well:

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

Hamid> If PW information length field is 0 then the GROUP ID field doesn't
       exist either. If the proposal implies that when PW length field
       is 0 it means there are fields that are present such as GROUP_ID
       and status field then the length field
       is no longer a length field but a type field where 0x00 value is
reversed.
       I am not in favor of overloading the length field to represent a type
       field. It is better to keep the length field to represent just length
       field...(doing that will avoid later on reserving other length field
       values to mean something else).

Hamid.

> -----Original Message-----
> From: [email-masked] [  <mailto:[email-masked]>
mailto:[email-masked]]
> Sent: Wednesday, July 02, 2003 4:33 PM
> Cc: [email-masked]
> Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-control-protocol-03.txt
>
>
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
> This draft is a work item of the Pseudo Wire Emulation Edge
> to Edge Working Group of the IETF.
>
>       Title           : Pseudowire Setup and Maintenance using LDP
>       Author(s)       : L. Martini, N. El-Aawar, E. Rosen
>       Filename        : draft-ietf-pwe3-control-protocol-03.txt
>       Pages           : 29
>       Date            : 2003-7-2
>      
> Layer 2 services (such as Frame Relay, ATM, ethernet) can be
> 'emulated' over an IP and/or MPLS backbone by encapsulating the layer
> 2 PDUs and then transmitting them over 'pseudowires'.  It is also
> possible to use pseudowires to provide SONET circuit emulation over
> an IP and/or MPLS network. This document specifies a protocol for
> establishing and maintaining the pseudowires, using extensions to
> LDP.  Procedures for encapsulating layer 2 PDUs are specified in a
> set of companion documents.
>
> A URL for this Internet-Draft is:
>  <http://www.ietf.org/internet-drafts/draft-ietf-pwe3-control-pr>
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-control-pr
otocol-03.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-pwe3-control-protocol-03.txt".

A list of Internet-Drafts directories can be found in
 <http://www.ietf.org/shadow.html> http://www.ietf.org/shadow.html
or  <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
        [email-masked].
In the body type:
        "FILE /internet-drafts/draft-ietf-pwe3-control-protocol-03.txt".
       
NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Luca Martini <[email-masked]>
Date: Mon, 14 Jul 2003 06:33:17 -0600

>    out what is the capability/intent of the remote PE (whether it supports
This point did not get enough support. We do not feel that we need a protocol 
to decide if the PW status notification message is used or not.
For backward compatibility an implementation specific local setting can 
definitely be used to achieve the correct behavior.

>    then the value of status signaling if it can't stop a remote PE from

First, if a mapping is received , it does mean then that PE that sent the 
mapping is ready to transmit. ALso please note that a PW status notification 
message indicating some other status ( other then the default one of "ready and 
working " ) can be sent together with the label mapping in the same LDP PDU.

> c) Ambiguity for the encoding for both the basic LDP notification and

This point is not clear. the PW tlv is different from the status tlv message.
Where is the ambiguity ?
As far as the length message , 0 has always meant only the group ID. This is 
what is currently implemented.  the length field does not measure the length of 
the group ID as it is fixed.

>    both PEs to support status signaling in order for the proposal to work.
Yes I agree with this point. The question is how much backward compatibility 
complexity do we need to include in this protocol ?
The most widely deployed implementation is ethernet , and status not very 
useful for ethernet vlan mode....

Thanks.
Luca

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