Subject: Re: [PWE3] draft-ietf-pwe3-vccv-07.txt - LAST CALL

From: Luca Martini <[email-masked]>
Date: Wed, 30 Nov 2005 14:49:50 -0700

Stewart,

Specific comments are in line below. However I have some general comments.
First it seems that this draft is not using the terminology in RFC3985,
Why ? Specifically what is a "Virtual Circuit" ? In this context it
could be the ATM VC inside the PW, or something else.
This needs to be made clear.
I am also concerned that there is no discussion of how status
notifications will be processed. This draft defines some situations that
requires sending a status notification, yet there is no specification of
which pw status message should be sent.
Another question to answer is what should a PE send ? For example , if 
all possible modes of VCCV are acceptable by the remote PE, what should 
be used ?
I think the answer is at most one mode at once.

Luca

Network Working Group                              T. D. Nadeau (Editor)
Internet Draft                                       Cisco Systems, Inc.
Expiration Date: February 2006
                                                     R. Aggarwal (Editor)
                                                         Juniper Networks

                                                              August 2005

       Pseudo Wire Virtual Circuit Connectivity Verification (VCCV)

                       draft-ietf-pwe3-vccv-07.txt

Status of this Memo

    By submitting this Internet-Draft, each author represents that any
    applicable patent or other IPR claims of which he or she is aware
    have been or will be disclosed, and any of which he or she becomes
    aware will be disclosed, in accordance with Section 6 of BCP 79.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-
    Drafts.

    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt.

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.

Abstract

    This document describes Virtual Circuit Connection Verification
    (VCCV) procedures for use with pseudo wire (PW) connections. VCCV
    supports connection verification applications for PWs regardless of
    the underlying public service network technology. VCCV makes use of
    IP-based protocols to perform operations and maintenance functions.
    This is accomplished by providing a control channel associated with
    each PW. A network operator may use the VCCV procedures to test the
    network's forwarding plane liveliness.

LM: what is the definition of a virtual circuit ?

A clearer text would be:
    This document describes Pseudo Wire Connection Verification
    (PWCV) procedures for use with pseudo wire (PW) connections.
    Connection verification applications are supported for PWs
regardless
    of the underlying public service network technology.
    Pseudo wire connection verification is supported by making use of
    IP-based protocols to perform operations and maintenance functions.
    A control channel associated with each PW is used to transport
    connection verification packets that can be used by the network
    operator to verify network's forwarding plane operation.

Table of Contents

PWE3 Working Group           Expires February 2006           [Page 1]

         draft-ietf-pwe3-vccv-07         VCCV       September 20, 2005

  1     Specification of requirements  ..........................   4
  2     Introduction  ...........................................   4
  3     Overview of VCCV  .......................................   5
  3.1   LSP Ping  ...............................................   6
  3.2   L2TPV3  .................................................   6
  3.3   Bidirectional Forwarding Detection  .....................   6
  4     VCCV Control Channels for PWs Demultiplexed using MPLS ..   7
  4.1   Inband VCCV  ............................................   7
  4.2   Out-of-Band VCCV  .......................................   8
  4.3   TTL Expiry VCCV  ........................................   8
  5     VCCV Types  .............................................   8
  5.1   MPLS LSP Ping Packet  ...................................   9
  5.2   Bidirectional Forwarding Detection  .....................   9
  6     OAM Capability Indication for PWs Demultiplexed using MPLS 10
  6.1   Optional VCCV Parameter  ................................  11
  7     VCCV Control Channel for L2TPv3/IP PSN  .................  12
  7.1   L2TPv3 VCCV Message  ....................................  13
  7.1.1 L2TPv3 VCCV ICMP Ping AVP  ..............................  13
  7.1.2 L2TPv3 VCCV BFD AVP  ....................................  13
  7.2   L2TPv3 VCCV Capability Indication  ......................  13
  7.2.1 L2TPv3 VCCV Capability AVP  .............................  13
  7.3   L2TPv3 VCCV Operation  ..................................  14
  8     IANA Considerations  ....................................  14
  8.1   VCCV Parameter ID  ......................................  14
  8.1.1 CC Types  ...............................................  15
  8.1.2 CV Types  ...............................................  15
  8.2   L2TPv3 Assignments  .....................................  15
  8.2.1 CV Types  ...............................................  15
  9     Security Considerations  ................................  15
10     Acknowledgements  .......................................  17
11     References  .............................................  17
11.1   Normative References  ...................................  17
11.2   Informative References  .................................  18
12     Editor Information ......................................  18
13     Contributor Information  ................................  19
14     Intellectual Property Statement  ........................  20
15     Full Copyright Statement  ...............................  20

1. Specification of requirements

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in [RFC2119].

2. Introduction

PWE3 Working Group           Expires February 2006           [Page 2]

         draft-ietf-pwe3-vccv-07         VCCV       September 20, 2005

    As network operators deploy pseudo wire (PW) services, fault detec-
    tion and diagnostic mechanisms particularly for the PSN portion of
    the network are pivotal. Specifically, the ability to provide end-to-
    end fault detection and diagnostics for an emulated PW service is
    critical for the network operator. Operators have indicated in
    [MPLSOAMREQS][PWREQ] that such a tool is required for PW deployments.
    This document describes procedures for PSN-agnostic fault detection
    and diagnostics called Virtual Circuit Connection Verification
    (VCCV).

                             |<----- Pseudo Wire ---->|
                             |                        |
                 Attachment  |  |<-- PSN Tunnel -->|  |   Attachment
                  Circuit    V  V                  V  V    Circuit
                     |     +----+                  +----+     |
           +----+    |     | PE1|==================| PE2|     |    +----+
           |    |----------|............PW1.............|----------|    |
           | CE1|    |     |    |                  |    |     |    |CE2 |
           |    |----------|............PW2.............|----------|    |
           +----+    |     |    |==================|    |     |    +----+
                ^          +----+                  +----+     |    ^
                |      Provider Edge 1         Provider Edge 2     |
                |                                                  |
                |<--------------- Emulated Service --------------->|
                             |<---------- VCCV ------>|
           Customer                                             Customer
           Edge 1                                                Edge 2

                Figure 1: PWE3 VCCV Operation Reference Model

    Figure 1 depicts the basic functionality of VCCV. VCCV provides sev-
    eral means of creating a control channel between PEs that attaches
    the PW under test.
LM:
If you must use the term VC , then it needs to be defined here.

       +-------------+                                +-------------+
       |  Layer2     |                                |  Layer2     |
       |  Emulated   |         Emulated Service       |  Emulated   |
       |  Services   |                                |  Services   |
       +-------------+                                +-------------+
       |             |         VCCV/PW                |             |
       |Demultiplexer|         Control Channel        |Demultiplexer|
       +-------------+                                +-------------+
       |    PSN      |            PSN Tunnel          |    PSN      |
       +-------------+                                +-------------+
       |  Physical   |                                |  Physical   |

PWE3 Working Group           Expires February 2006           [Page 3]

         draft-ietf-pwe3-vccv-07         VCCV       September 20, 2005

       +-----+-------+                                +-----+-------+
             |                                              |
             |             ____     ___       ____          |
             |           _/    ___/       _/    __       |
             |          /               __/         _     |
             |         /                                   |
             ---------|      MPLS or IP Network        |-----
                                                      /
                          ___      ___     __      _/
                        _/   ____/   ___/  ____/

          Figure 2: PWE3 Protocol Stack Reference Model
                    including the VCCV control channel.
LM: Can you please fix this picture ?
if you use the xml or nroff macros it saves time for the rfc editor ,
and trouble like this ....

    Figure 2 depicts how the VCCV control channel is associated with the
    pseudo wire. Ping and other IP messages are encapsulated using the
    PWE3 encapsulation as described below in sections 5 and 6. These mes-
    sages, referred to as VCCV messages, are exchanged only after the
    desire to exchange such traffic has been negotiated between the PEs
    (see section 8).

3. Overview of VCCV

    VCCV defines a set of messages that are exchanged between PEs to ver-
    ify connectivity of the pseudo wire. To make sure that VCCV packets
    follow the same path as the PW data flow, they are encapsulated in
    the PW demultiplexer and trasported over the PSN tunnel.  VCCV can
    operate in two modes:

     1) as a diagnostic tool
     2) as a fault detection tool

    In the diagnostic mode, the operator triggers LSP-Ping, L2TPV3, or
    ICMP Ping [ICMP] modes depending on the underlying PSN. Since a PW
    service is bi-directional, the reply SHOULD be sent over the PW in
    the reverse direction, that makes up the other half of the PW service
    under test. For example, if the PSN is MPLS, the reply should be sent
    over the reverse PW, which is transported over the PSN LSP in the

LM: nothing should be sent over the reverse PW.
it should be sent over the PW associated channel in the reverse direction.

    reverse direction. If this fails, the operator may use other reply
    modes to determine the fault [LSP-PING].

    The fault detection mode provides a way to emulate fault detection
    mechanisms in other technologies, such as ATM for example. For exam-
    ple, in the fault detection mode, the BFD Bidirectional Forwarding
    Detection (BFD) mechanism can be used as following: the upstream PE
    sends BFD control messages periodically. When the downstream PE
    doesn't receive these message for a defined period of time, it

PWE3 Working Group           Expires February 2006           [Page 4]

         draft-ietf-pwe3-vccv-07         VCCV       September 20, 2005

    declares that direction of the PW down and it notifies the upstream
    PE. Based on the emulated service, the PEs may send native indica-

LM: How do we notify the upstream PE ?

    tions over the related attachment circuits to notify the end points
    of the fault condition. The specific details of the handling of these
    conditions is out of the scope of this document, and are only noted
    here to illustrate the utility of VCCV for these purposes.

3.1. LSP Ping

    When PWs are demultiplexed using MPLS, LSP Ping is used as described
    in [LSP-PING] as a connectivity verification and diagnostic tool for
    PWs. The PSN may be MPLS or IP.

3.2. L2TPV3

    When IP is used as the PSN, various protocols can be deployed for PW
    Demultiplexing [PWEARCH]. If L2TP or UDP is used, ICMP ECHO packets
    [ICMP] can be used as the means by which connectivity verification is
    achieved.

3.3. Bidirectional Forwarding Detection

    When fault detection indication is necessary for one or more PWs, the
    Bidirectional Forwarding Detection (BFD) [BFD] provides a light-
    weight means of continuous monitoring and propagation of forward and
    reverse defect indications.  BFD can be used regardless of the under-
    lying PSN technology.

4. VCCV Control Channels for PWs Demultiplexed using MPLS

    In order to apply IP monitoring tools to PWE3 circuits, VCCV creates
    a control channel between PWE3 PEs [PWEARCH].  Packets sent across
    this channel are IP packets, allowing maximum flexibility.

    Ideally such a control channel would be completely in band.  When a
    control word is present on virtual circuit, it is possible to indi-
    cate the control channel by setting a bit in the control header.

LM: Nit , the text below is probably not needed.

    This method is described in section 4.1 and is referred to as PWE3
    inband VCCV.

4.1. Inband VCCV

    The PW set-up protocol [PWSIG] determines whether a PW uses a control
    word. When a control word is used, it SHOULD have the following form

LM: what form ?
this text does not parse

PWE3 Working Group           Expires February 2006           [Page 5]

         draft-ietf-pwe3-vccv-07         VCCV       September 20, 2005

    for the purpose of indicating VCCV control channel messages. (Note
    that for data, one uses the control word defined just above the MPLS
    payload [PWEARCH].)

LM: one ? Grammar needs fixing. ;-)

    The PW Associated Channel for VCCV control channel traffic is defined
    as follows in [PW-CW]:

       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 0 0 1| FmtID |   Reserved    |         Channel Type          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 3: PW Associated Channel Header

    The first nibble is set to 0x0001. The Format ID and the reserved
    fields are set to 0 and the channel type is used as defined in [PW-
    CW, PWE3IANA].

    For example, the following is an example of how the ethernet control
    word would be received [ENETENCAP]:

           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 0 0 1|  0                   | Channel Type                   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 4: PW Associated Channel Header for VCCV

LM: picture is broken , needs a bunch of 0's and aligment.

    It should be noted that PWs are not required to carry the control
    word, and that this method can only be used for those PWs that do.

4.2. Out-of-Band VCCV

    When the control word is not used, or the receiving hardware cannot
    divert control traffic based on information in the control word
    (i.e.: older hardware), a VCCV control channel can be created alter-
    natively by including the MPLS router alert label [RFC3032] immedi-
    ately above the PW label. If the control word is in use on this PW it
    is also included in the VCCV control flow. It should be noted that
LM: here we say that the Cw is used , but also the router alert is used 
? Is this negotiated ?

    this approach may alter equal cost multi-path (ECMP) hashing behav-
    ior, and thus the VCCV traffic may take a path which differs from
    that of the data traffic under test.

PWE3 Working Group           Expires February 2006           [Page 6]

         draft-ietf-pwe3-vccv-07         VCCV       September 20, 2005

4.3. TTL Expiry VCCV

    The TTL of the PW demultiplexor label can be set to 1 to force the
    packet to be processed within the destination router's control plane.
    This is an inband control channel identification mechanism that is an
    alternate to section 4.1.

LM: this needs to be clearer. The TTL of the PW demultiplexor label 
stack .... why would the ttl of the other labels be something else ?

    When the PSN is MPLS it should be noted that this mode may not work
    in cases where the penultimate hop overwrites the TTL values of
    labels underneath the top-most label. Some older implementations do
    this, and the result would be a false positive. Therefore, we recom-
    mend that operators investigate the TTL handling behavior of the
    routers in their networks to determine if this situation can occur.
    If it is discovered that it can, than this mode should not be used
    for the reasons explained above.

LM: I believe that we should drop the "older implementations" ( 
everywhere ) part ...
Let's stick to RFCs here. What does RFC3032 say in this matter ?

5. VCCV Types

    VCCV can carry several types of protocols that can be used on the
    control channel either at the same time, or serially.  The specific
    type or types of VCCV packets accepted by a router are indicated dur-
    ing signaling as described in section 6.  The various VCCV types sup-
    ported SHOULD be used only when they apply to the PW demultiplexor in
LM: Ok, so  when can the  LSP Ping type be used with IP ?
The point is that if this is a SHOULD then you need to explain why one 
should not do this ...
Bottom line this need to be a MUST.

    use. For example, the LSP Ping type should only be used when MPLS is
    utilized as the PW demultiplexor.

5.1. MPLS LSP Ping Packet

    The LSP Ping header must be used as described [LSP-PING] and must

LM: must need to be capital ...

    also contain the sub-TLV of 8 for the L2 VPN endpoint or 9 for the L2
    circuit ID. The sub-TLV indicates the PW to be verified.

5.2. Bidirectional Forwarding Detection

    When heart-beat indication is necessary for one or more PWs, the
    Bidirectional Forwarding Detection (BFD) [BFD] provides a light-
    weight means of continuous monitoring and propagation of forward
    and reverse defect indications.

    In order to use BFD, both ends of the PW connection must have sig-
    naled the existence of a control channel and the ability to run BFD.
    Once a node has both signaled and received signaling from its peer of
    these capabilities, it MUST begin sending BFD control packets. The
    packets MUST be sent on the control channel. The use of the control
    channel provides the context required to bind the BFD session to a
    particular PW (FEC). Thus normal BFD initialization procedures are

PWE3 Working Group           Expires February 2006           [Page 7]

         draft-ietf-pwe3-vccv-07         VCCV       September 20, 2005

    followed. BFD MUST be run in asynchronous mode. In addition, it may
    also be desirable to use LSP-Ping for periodic diagnostics, in addi-
    tion to BFD, for fault detection on the same PW. The procedures for
    this are described in [BFDMPLS].

    When one of the PEs (PE2) doesn't receive control messages from PE1
    during the specified amount of time it declares that the PW in the
    direction from PE2 to PE1 is down.  It stores the cause (e.g., con-
    trol detection time expired) and sends a message to PE1 with H (i.e.,
    "I don't hear you"). This causes PE1 to declare the PW in the direc-
    tion from PE1 to PE2 down and it stores as cause: neighbor signaled
    session down.  Depending on the emulated services, PE2 may send a
    forward direction indication (FDI) indication on its attachment
    circuits and PE1 may send an RDI indication on its attachment
    circuits [OAM-MAP].

LM: I see a big problem here. How is the message sent ? using BFD ?
We have a status notification mechanisms in the control protocol. I 
believe that the control protocol can be more reliable then inband 
notifications in most cases.
I believe that you should specify the use of the BFD status notification 
method only if there is no other control protocol status message facility.
At minimum you must define who will be the master of the status, and why 
one should not follow the control protocol procedures ...

    BFD defines the following diagnostics:

           0 -- No Diagnostic
           1 -- Control Detection Time Expired
           2 -- Echo Function Failed
           3 -- Neighbor Signaled Session Down
           4 -- Forwarding Plane Reset (Local equipment failure)
           5 -- Path Down (Alarm Suppression)
           6 -- Concatenated Path Down (Propagating access link alarm)
           7 -- Administratively Down

    Note that the value, 0 is used when the PW is up and 2 is not appli-
    cable to asynchronous mode.

6. OAM Capability Indication for PWs Demultiplexed using MPLS

    To permit the indication of the type or types of PW control chan-
    nel(s), and connectivity verification mode or modes over a particular
    PW, a VCCV parameter is defined below that is used as part of the PW
    establishment signaling.  When a PE signals a PW and desires PW OAM
    for that PW, it MUST indicate this during PW establishment using the
    messages defined below. Specifically, for LDP the PE MUST include the
    VCCV parameter in the PW setup message.

LM: for LDP ? you mean when using the pwe3 control protocol .....

    The decision of the type of VCCV control channel is left completely
    to the receiving control entity. When a PE sends a label for a PW, it

LM: terminology: PE send a label mapping message for a PW

    uses the VCCV parameter to indicate the type of OAM control channels
    and connectivity verification type or types it is willing to receive
    on that PW. The capablity of supporting a control channel or chan-
LM: spelling        ^^^^^^

    nels, and connectivity type or types used over that control channel
    or channels MUST be signaled before the remote PE may send VCCV mes-
    sages, and then only on the control channel or channels, and using

PWE3 Working Group           Expires February 2006           [Page 8]

         draft-ietf-pwe3-vccv-07         VCCV       September 20, 2005

    the connectivity verification type or types indicated.

LM: ok, so we send a sting of bits that say " I can receive , router 
alert, I can also receive CW associated channel"
Does this mean that both must be used ? or only one ?
If only one , then there is a conflict with text above ...

    If a PE receives VCCV messages prior to advertising capability for
    this message, it MUST discard these messages and not reply to them.
    In this case, the PE SHOULD increment an error counter and optionally
    issue a system and/or SNMP notification to indicate to the system
    administrator that this condition exists.

    When LDP is used as the PW signaling protocol the requesting PE indi-
    cates its configured VCCV capability or capabilities to the remote PE
    by including the VCCV parameter with appropriate options indicating
    which methods of OAM it supports in the interface parameter field of
    the PW ID FEC TLV (FEC 128) or in the interface parameter TLV of the
    Genralized PW ID FEC TLV (FEC 129). The requesting PE MAY indicate
    that it supports multiple control channel options, and in doing so
    agrees to support any and all indicated types if transmitted to it.
    Local policy may direct the PE to support certain OAM capability and
    to indicate it. The absence of the VCCV parameter indicates that no
    OAM functions are supported by the requesting PE, and thus the
    receiving PE MUST NOT send any VCCV control channel traffic to it.
    The reception of a VCCV parameter with no options set MUST be ignored
    as if one is not transmitted at all.

    The receiving PE agrees to accept any of the indicated OAM types and
    options by virtue of establishing the PW. If it does not or cannot
    support at least one of the options specified, it MUST not establish
    the PW. If the requesting PE wishes to continue, it may choose dif-
    ferent options and try to signal the PW again.

6.1. Optional VCCV Parameter

    [PWE3CONTROL] defines an Interface Parameter field in the LDP PW ID
    FEC (FEC 128) and an Interface Parameters TLV in the LDP Generalized
    PW ID FEC (FEC 129) to signal different capabilities for specific
    PWs. We propose an optional parameter to be used to indicate the
    desire to use a control channel for VCCV. This is the VCCV parameter
    field. If FEC 128 is used the VCCV parameter field is carried in the
    Interface Parameters field. If FEC 129 is used it is carried as a
    sub-TLV in the Interface Parameters TLV.

    The VCCV parameter ID is defined as follows in [PWE3IANA]:

         Parameter ID   Length     Description
           0x0c           4           VCCV

    The format of the VCCV parameter field is as follows:

       0                   1                   2                   3

PWE3 Working Group           Expires February 2006           [Page 9]

         draft-ietf-pwe3-vccv-07         VCCV       September 20, 2005

       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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      0x0c     |       0x04    |   CC Types    |   CV Types    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

LM: picture needs fixing ...

LM: what is a CV type ?

    The Control Channel (CC Types) type field defines a bitmask used to
    indicate the type of control channel(s) (i.e.: none, one or both)
    that may be used to receive OAM control channel traffic on. If more
    than one control channel is specified, the router agrees to accept
    control traffic at any time over either control channel. If none of

LM:but what should be sent ? both channels ? or just one ?
I think you should specify that one should be used when sending ...

    the types are supported, a CC Type Indicator of 0x00 SHOULD be trans-
    mitted to indicate this to the peer. However, if no capability is
    signaled, then the peer MUST assume that the peer is incapable of
    receiving VCCV and MUST NOT send any OAM control channel traffic to
    it.

        0x01 PWE3 control word with 0x0001 as first nibble
        0x02 MPLS Router Alert Label
        0x04 MPLS PW Demultiplexor Label TL = 1

LM:  TL ? it should be TTL
Also i believe that combining of these types should be specifically not 
be allowed. For example the use of a CW with TTL=1.

    The CV Type Indicators field is a bitmask used to indicate the spe-
    cific type or types (i.e.: none, one or more) of control channel
    packets that may be sent on the specified control channel.  The
    defined values are:

        0x01  ICMP Ping
        0x02  LSP Ping
        0x04  BFD for PW Fault Detection only
        0x08  BFD for PW Fault Detection and AC/PW Fault
              Status Signaling

    It should be noted that two different CV Types have been defined
    when BFD is used. In the first case, type 0x04 indicates that
    BFD is used exclusively to detect faults on the PW and the
    status of those faults should be conveyed using some means other
    than BFD.  In the case of type 0x08, the AC and PW status SHOULD
    be conveyed via BFD status codes as specified in [OAM-MAP].
LM:
In the case when the control protocol is used , I believe that a clear 
statement need to be made on how all of this will work. Le me give an 
example : In an ATM VC PW case , the receiving PE will receive an AIS 
alarm. It will then issue a BFD equivalent, and a PW status message for 
AC TX fault ... When this gets cleared a race condition will arise, and 
the PW may never work again.
Note that this has nothing to do with the message mapping, it's simply a 
conflict between several asynchronous state machines.

    If none of the types above are supported, a CV Type Indicator of 0x00
    SHOULD be transmitted to indicate this to the peer. However, if no
    capability is signaled, then the peer MUST assume that the peer has
    no VCCV capability.

7. VCCV Control Channel for L2TPv3/IP PSN

    When L2TPv3 is used to setup a PW over an IP PSN, VCCV packets are
    carried over the L2TPv3 session as defined in this section. It should

PWE3 Working Group           Expires February 2006          [Page 10]

         draft-ietf-pwe3-vccv-07         VCCV       September 20, 2005

    be noted that L2TPv3 has a built-in "Hello" keepalive mechanism for
    its control plane that operates "in-band" over IP with respect to the
    IP protocol number, port (when UDP is used), source and destination
    IP addresses. This built-in Hello mechanism provides connection sta-
    tus only for the group of sessions associated with the L2TP Control
    Channel. VCCV, however, allows individual L2TP sessions to be tested.
    This provides a more granular mechanism which can be used to trou-
    bleshoot potential problems deeper within the dataplane of L2TP end-
    points themselves, or to provide additional connection status of
    individual pseudo wires.

LM: so which method  is to be believed if there is a conflict ?

    In order to carry VCCV messages within an L2TPv3 session data packet,
    this draft relies on the presence of the L2-Specific Sublayer. The
    presence of this field is signaled via the L2-Specific Sublayer AVP
    as defined in [L2TPv3]. The 'V' bit within the Default L2-Specific
    Sublayer is used to identify that a VCCV message follows.

        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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |V|S|x|x|x|x|x|x|              Sequence Number                  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Default L2-Specific Sublayer Format with V bit.

    The 'V' bit indicates that a VCCV session message follows.  If the PW
    has not been signaled to include a L2-specific sublayer format, other
    mechanisms are needed to indicate the VCCV message.  Such mechanisms
    are for further study.

7.1. L2TPv3 VCCV Message

    The VCCV message MUST contain a VCCV AVP. It does not contain a mes-
    sage header. This could either be a new VCCV ICMP Ping AVP or VCCV
    BFD AVP. The usage of the L2TPv3 AVP format leaves room for adding
    further AVPs to this message in the future as needed.

LM: where is this APV defined ?

7.1.1. L2TPv3 VCCV ICMP Ping AVP

    This AVP encodes the ICMP Ping Echo Packet [ICMP]. This AVP may be
    followed by the L2TPv3 Remote End Identifier AVP to identify the PW
    associated with the session.

7.1.2. L2TPv3 VCCV BFD AVP

PWE3 Working Group           Expires February 2006          [Page 11]

         draft-ietf-pwe3-vccv-07         VCCV       September 20, 2005

    This AVP encodes a BFD packet that is used to verify the session.
    When heart-beat indication is necessary for one or more PWs, the
    Bidirectional Forwarding Detection (BFD) [BFD] provides a light-
    weight means of continuous monitoring and propagation of forward and
    reverse defect indications.

    BFD MUST be run in asynchronous mode. BFD control packets [BFD] are
    encapsulated in the AVP. The L2TPv3 session provides the context to
    demultiplex the first BFD control packet.

    The L2TPv3 VCCV BFD AVP may be followed by the L2TPv3 Remote End
    Identifier AVP to identify the PW associated with the session.

7.2. L2TPv3 VCCV Capability Indication

    A LCCE or a LAC should be able to indicate whether the session is
    capable of processing VCCV packets. This is done by including the
    optional VCCV capability AVP in an ICRQ, ICRP, OCRQ or OCRP.

7.2.1. L2TPv3 VCCV Capability AVP

LM: to make it clear you should move this section up. SO you can answer 
my question above ... before goin into the detail of how this is used ...

    This AVP specifies the VCCV capability. Its attribute type is TBD.
    The value field has the following format:

           0                   1
           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          | Reserved     | CV Type        |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The CV Type Indicators field defines a bitmask used to indicate the
    specific type or types (i.e.: none, one or more) of IP control pack-
    ets that may be sent on the specified control channel. The defined
    values are:

        0x01  ICMP Ping
        0x02  BFD

    If none of the types above are supported, a CV Type Indicator of 0x00
    SHOULD be transmitted to indicate this to the session peer.  However,
    if no capability is signaled, then the peer MUST assume that the
    other peer has no VCCV capability.

7.3. L2TPv3 VCCV Operation

PWE3 Working Group           Expires February 2006          [Page 12]

         draft-ietf-pwe3-vccv-07         VCCV       September 20, 2005

    A PE sends VCCV echo requests on a L2TPv3 signaled PW for fault
    detection and diagnostic of the L2TPv3 session. The destination IP
    address in the echo request is set to the remote PE's IP address,
    while the source IP address is set to the local PE's IP address. The
    egress of the L2TPv3 session verifies the signaling and forwarding
    state of the PW, on reception of the VCCV message. Any faults
    detected can be signaled in the VCCV echo response. Its to be noted
    that the VCCV mechanism for L2TPv3 is primarily targeted at verifying
    the PW forwarding and signaling state at the egress PE. It also helps
    when L2TPv3 control and session paths are not identical.

    A PE must send VCCV packets on a L2TPv3 session only if it has sig-
    naled VCCV capability to the remote end and received VCCV capability
    from the remote end. If a PE receives VCCV packets and its not VCCV
    capable or it has not received VCCV capability indication from the
    remote end, it must discard these messages. In addition if a PE
    receives VCCV messages and it has not received VCCV capability from
    the remote end, it should increment an error counter. In this case
    the PE can optionally issue a system and/or SNMP notification.

8. IANA Considerations

LM: this IANA section needs re-writing. First I think you need to 
section the iana allocation ranges in a similar fashion as to the PWE3 
iana document.

8.1. VCCV Parameter ID

    VCCC parameter ID codepoint is defined in [PWE3IANA]. IANA is
    requested to maintain a registry for the CC Types and CV Types, bit-
    masks in the VCCV parameter ID. The allocations must be done using
    the "First Come First Served" policy defined in RFC2434. IANA is
    requested to reserve the following bits in this registry:

8.1.1. CC Types

        0x01 PWE3 control word with 0x0001 as first nibble
        0x02 MPLS Router Alert Label
        0x04 MPLS PW Demultiplexor Label TL = 1

8.1.2. CV Types

        0x01  ICMP Ping
        0x02  LSP Ping
        0x04  BFD

8.2. L2TPv3 Assignments

PWE3 Working Group           Expires February 2006          [Page 13]

         draft-ietf-pwe3-vccv-07         VCCV       September 20, 2005

    The 'V' bit within the L2TPv3 Default L2-Specific Sublayer has to
    assigned by IANA. L2TPv3 VCCV ICMP Ping AVP, BFD AVP, VCCV Capability
    AVP must also be assigned by IANA. IANA is requested to maintain a
    registry for the CV Types, bit-mask in the VCCV Capability AVP. The
    allocations must be done using the "First Come First Served" policy
    defined in RFC2434. IANA is requested to reserve the following bits
    in this registry:

8.2.1. CV Types

        0x01  ICMP Ping
        0x02  BFD

----------------------------------------------------
New iana section:

.Pa "IANA Considerations"

  The IANA registries defined here, are in general subdivided into
three main ranges: a range to be allocated by IETF consensus according 
to [RFC2434], a range to be allocated by the expert review process 
according to [RFC2434], and a range to be allocated in a first come 
first served basis reserved for vendor proprietary allocations. It 
should be noted that vendor proprietary types MUST NOT be registered for
IETF standards or extensions of those, whether still in development or
already completed.

IANA is requested to create several registries as described in the 
following sections. Each of these registries contains numeric values 
used to identify data types. In each of these registries the value of 0 
is reserved,

.Pb "Expert Review Directives"
Throughout this document allocation procedures for several registries 
call for an expert review process according to [RFC2434]. The expert 
should consider the following points:

.Pz *
Avoid Duplication of code point allocations.
.Pz *
A brief clear description of the code point allocation requested.
.Pz *
Whether the type allocation requested is appropriate for the particular
requested value range in the registry.
.En

The Expert reviewing the request MUST provide an answer, approving, or
disapproving the request within 10 business days from when the he or she
received the expert review request.

.Pb "VCCV Parameter ID"

VCCV parameter ID codepoint is already allocated in [PWE3IANA].

.Pb "Control Channel Type"

IANA needs to set up a registry of "Control Channel Type". These are
bit strings of length 8. Bits 0 to 2 are defined in this document.CC 
Type bits 3 to 7 are to be assigned by IANA using the "Expert Review" 
policy defined in [RFC2434].

Any requests for allocation from this registry require a description up
to 65 characters.

Initial  Control Channel Type allocations are as follows:

0x01 PWE3 control word with 0x0001 as first nibble
0x02 MPLS Router Alert Label
0x04 MPLS PW Demultiplexor Label TTL = 1

.Pb "Control V????? Type"

IANA needs to set up a registry of "Control V????? Type". These are
bit strings of length 8. Bits 0 to 2 are defined in this document.CV 
Type bits 3 to 7 are to be assigned by IANA using the "Expert Review" 
policy defined in [RFC2434].

Any requests for allocation from this registry require a description up
to 65 characters.

Initial  Control V?????? Type allocations are as follows:

0x01  ICMP Ping
0x02  LSP Ping
0x04  BFD

.Pb "L2TPv3 allocations"

[The 'V' bit within the L2TPv3 Default L2-Specific Sublayer has to be
assigned by IANA.] this section does not parse - please fix.

Iana should assign values for the following Attribute Value Pairs from 
the "Control Message Attribute Value Pairs" registry:

    Value Description
     TBD  VCCV ICMP Ping AVP
     TBD  Bidirectional Forwarding Detection (BFD) AVP
     TBD  VCCV Capability

[ editor note :  VCCV Capability AVP must use the same format and CV/CC 
types as in the PW capability sub-tlv ]

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

9. Security Considerations

    Routers that implement the mechanism described herein are subject to
    to additional denial-of-service attacks as follows:

      An intruder may impersonate an LDP peer in order to
      force a failure and reconnection of the TCP connection, but
      where the intruder sets the Recovery Time to 0 on
      reconnection.

      An intruder could intercept the traffic between LDP or
      peers and override the setting of the TCP Recovery Time to
      be set to 0.

      An intruder could inject traffic into the TCP connection
      and effectively masquerade as an LDP peer. The same is
      possible for the UDP stream between L2TPv3 peers. In doing
      so could falsely indicate VCCV capabilities to a peer.

      An intruder could intercept or inject VCCV packets effectively
      providing false positives or false negatives.

      An intruder could deliberately flood a peer router with VCCV
      messages to either obtain services without authorization or to
      deny services to others.

      A misconfigured or misbehaving device could inadvertantly flood
      a peer router with VCCV messages which could result in a denial
      of services. In particular, if a router is either implicitly or
      explicitly indicated that it cannot support one or all of the
      types of VCCV, but is sent those messages in sufficient quantity,
      could result in a denial of service.

PWE3 Working Group           Expires February 2006          [Page 14]

         draft-ietf-pwe3-vccv-07         VCCV       September 20, 2005

    All of attacks above which concern the L2TPv3 or LDP control planes
    may be countered by use of a control message authentication scheme
    between LDP or L2TPv3 peers, such as the MD5-based scheme outlined in
    [LDP] or [L2TPv3]. Implementation of IP address filters may also aid
    in deterring these types of attacks.

    VCCV message throttling mechanisms should be employed, especially in
    distributed implementations which have a centralized control plane
    processor with various line cards attached by some data path. In
    these architectures VCCV messages may be processed on the central
    processor after being forwarded there by the receiving line card. In
    this case, the path between the line card and the control processor
    may become saturated if appropriate VCCV traffic throttling is not
    employed, which could lead to a denial of service.  Such filtering is
    also useful for preventing the processing of unwanted VCCV messages,
    such as those which are sent on unwanted (and perhaps unadvertised)
    control channel types or VCCV types.

    VCCV spoofing requires MPLS PW label spoofing and spoofing the PSN
    tunnel header. As far as the PW label is concerned the same consider-
    ations as specified in [RFC3031] apply. If the PSN is a MPLS tunnel,
    PSN tunnel label spoofing is also required.

10. Acknowledgements

    The authors would like to thank Hari Rakotoranto, Michel Khouderchah,
    Bertrand Duvivier, Vanson Lim, Chris Metz, W. Mark Townsley, Eric
    Rosen, Dan Tappan,Danny McPherson and Luca Martini for their valuable
    comments and suggestions.

11. References

11.1. Normative References

    [RFC2119] "Key words for use in RFCs to Indicate Requirement
              Levels.", Bradner, March 1997

    [BFD]      Katz, D., Ward, D., Bidirectional Forwarding
               Indication, draft-ietf-bfd-03.txt, July 2005

    [PWE3IANA] Martini, L., Townsley, M., "IANA Allocations for
               pseudo Wire Edge to Edge Emulation (PWE3)",
               draft-ietf-pwe3-iana-allocation-11.txt, June
               2005.

    [IANAPPP]  IANA Point-to-Point Protocol Field Assignments,
               April 12, 2004,

PWE3 Working Group           Expires February 2006          [Page 15]

         draft-ietf-pwe3-vccv-07         VCCV       September 20, 2005

               http://www.iana.org/assignments/ppp-numbers

    [LSPPING]  Kompella, K., G. Swallow, " Detecting MPLS Data Plane
               Failures", Internet Draft draft-ietf-mpls-lsp-ping-09.txt,
               May 2005.

    [PWCTRL]   Martini, L., et. al., "Pseudo Wire Setup and Maintenance
               using LDP", draft-ietf-pwe3-control-protocol-17.txt,
               June 2005

    [ENETENCAP] Martini, L., et. al., "Encapsulation Methods for Trans-
    port
                of Ethernet Frames Over IP/MPLS Networks",
                draft-ietf-pwe3-ethernet-encap-10.txt, June 2005.

    [RFC3032]  Rosen, E., Rehter, Y., Tappan, D., Farinacci, D.,
    Fedorkow,
               G., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC
               3032, January 2001.

    [L2TPv3]   J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling
               Protocol version 3", draft-ietf-l2tpext-l2tp-base-12.txt,
               March 2004.

    [ICMP]     Postel, J. "Internet Control Message Protocol,  RFC 792

    [LDP]      Andersson, L., Doolan, P., Feldman, N., Fredette, A.
               and B. Thomas, "Label Distribution Protocol", RFC
               3036, January 2001.

    [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon,
               "Multiprotocol Label Switching Architecture", RFC
               3031, January 2001.

    [PW-CW]    S. Bryant et. al., "PWE3 Control Word for use over an
               MPLS PSN", draft-ietf-pwe3-cw-05.txt, June 2005.

11.2. Informative References

    [MPLSOAMREQS] Nadeau, T., et al,"OAM Requirements for MPLS
                  Networks, Internet Draft
                  draft-ietf-oam-requirements-02.txt, June 2003.

    [PWEARCH]     Bryant, S., Pate, P., "PWE3 Architecture", RFC 3985,
                  March 2005

    [PWREQ]       Xiao, X., McPherson, D., Pate, P., "Requirements for

PWE3 Working Group           Expires February 2006          [Page 16]

         draft-ietf-pwe3-vccv-07         VCCV       September 20, 2005

                  Pseudo Wire Emulation Edge to-Edge (PWE3)",
                  draft-ietf-pwe3-requirements-08.txt, December 2003

    [BFDMPLS]     R. Aggarwal, et al, "BFD for MPLS LSPs", Internet
                  Draft <draft-ietf-bfd-mpls-02.txt>, June 2005.

    [RFC2434]     Narten, T. and H. Alvestrand.,  "Guidelines for Writing
                  an IANA Considerations Section in RFCs", BCP 26, RFC
                  2434, October 1998.

    [OAM-MAP]     T. Nadeau, et. al, "Pseudo Wire (PW) OAM Message Map-
                  ping", draft-ietf-pwe3-oam-msg-map-03.txt,
                  September 2005

12. Editor Information

    Thomas D. Nadeau
    Cisco Systems, Inc.
    300 Beaver Brook Road
    Boxborough, MA 01719
    Email: [email-masked]

    Rahul Aggarwal
    Juniper Networks
    1194 North Mathilda Ave.
    Sunnyvale, CA 94089
    Email: [email-masked]

13. Contributor Information

    George Swallow
    Cisco Systems, Inc.
    300 Beaver Brook Road
    Boxborough, MA 01719
    Email: [email-masked]

    Monique Morrow
    Cisco Systems, Inc.
    Glatt-com
    CH-8301 Glattzentrum
    Switzerland
    Email: [email-masked]

    Yuichi Ikejiri
    NTT Communication Corporation
    1-1-6, Uchisaiwai-cho, Chiyoda-ku

PWE3 Working Group           Expires February 2006          [Page 17]

         draft-ietf-pwe3-vccv-07         VCCV       September 20, 2005

    Tokyo 100-8019
    Shinjuku-ku, JAPAN
    Email: [email-masked]

    Kenji Kumaki
    KDDI Corporation
    KDDI Bldg. 2-3-2,
    Nishishinjuku,
    Tokyo 163-8003,
    JAPAN
    E-mail: [email-masked]

    Peter B. Busschbach
    Lucent Technologies
    67 Whippany Road
    Whippany, NJ, 07981
    E-mail: [email-masked]

    Vasile Radoaca
    Nortel Networks
    Billerica, MA, 01803
    Email: [email-masked]

14. Intellectual Property Statement

    The IETF takes no position regarding the validity or scope of any
    Intellectual Property Rights or other rights that might be claimed to
    pertain to the implementation or use of the technology described in
    this document or the extent to which any license under such rights
    might or might not be available; nor does it represent that it has
    made any independent effort to identify any such rights.  Information
    on the procedures with respect to rights in RFC documents can be
    found in BCP 78 and BCP 79.

    Copies of IPR disclosures made to the IETF Secretariat and any
    assurances of licenses to be made available, or the result of an
    attempt made to obtain a general license or permission for the use of
    such proprietary rights by implementers or users of this specification
    can be obtained from the IETF on-line IPR repository at
    http://www.ietf.org/ipr.

    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights that may cover technology that may be required to implement
    this standard.  Please address the information to the IETF at ietf-
    [email-masked].

PWE3 Working Group           Expires February 2006          [Page 18]

         draft-ietf-pwe3-vccv-07         VCCV       September 20, 2005

15. Full Copyright Statement

    Copyright (C) The Internet Society (2005).  This document is subject
    to the rights, licenses and restrictions contained in BCP 78, and
    except as set forth therein, the authors retain all their rights.

    This document and the information contained herein are provided on an
    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

PWE3 Working Group           Expires February 2006          [Page 19]

Stewart Bryant wrote:
> This is the start of a two week last call for
> 
> Pseudo Wire Virtual Circuit Connectivity Verification (VCCV)
> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-07.txt
> 
> Last call will end at 9AM UK on Wednesday 12th October.
> 
> - Stewart
> 
> 
> 
> 
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3

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