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

From: Carlos Pignataro <[email-masked]>
Date: Mon, 10 Oct 2005 22:53:43 -0400

"Please find some comments marked `***CP', I hope they are useful.

---

         Figure 2: PWE3 Protocol Stack Reference Model
                   including the VCCV control channel.

***CP: The ascii artwork in this figure got corrupted.

---

3. Overview of VCCV

   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.

***CP: Is the above a generic statement? I wonder if for example for LSP
***CP: Ping a new `Reply mode' needs to be defined in support of this
***CP: requirement, since existing reply modes do not allow for "reply
***CP: over PW reverse direction"; only as UDP/IP (with or w/o RA)
***CP: packet, and "application level control channel" (LDP).

---

5.1. MPLS LSP Ping Packet

   The LSP Ping header must be used as described [LSP-PING] and must
   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.

***CP: Should probably clarify sub-TLV of Target FEC Stack TLV. Also TFS
***CP: Sub-Type 9 has been deprecated in favor of 10 (and renamed to
***CP: `"FEC 128" Pseudowire'), and sub-Type 11 ("FEC 129" Pseudowire)
***CP: is also significant.

---

5.2. Bidirectional Forwarding Detection

   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.

***CP: Should be "in the direction from PE1 to PE2 is down" (reversed).

---

5.2. Bidirectional Forwarding Detection

   session down.  Depending on the emulated services, PE2 may send a
   forward direction indication (FDI) indication on its attachment

***CP: Redundant "indication".

---

6. OAM Capability Indication for PWs Demultiplexed using MPLS

   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

***CP: Should change `interface parameter field' with sub-TLV.

---

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

***CP: Interface Parameter sub-TLV.

---

6.1. Optional VCCV Parameter

   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)

***CP: "none, one or more" (instead of "both"), since there's more than
***CP: two now.

---

7. VCCV Control Channel for L2TPv3/IP PSN

***CP: This section for L2TPv3 as demux does not seem to specify a
***CP: associated channel, but instead a VCCV-only channel, since
***CP: there's no ACH with a PID. That is, uses the same L2SS format
***CP: when V=1 (instead of an ACH). If this is the intention, it should
***CP: define how to use the `Sequence #' field in the Default L2SS.

---

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.

***CP: Some clarifications may be needed here with the use and
***CP: definition of AVPs, since AVPs are defined in the context of
***CP: L2TPv3 control messages. i.e., what's the relationship between
***CP: the newly defined AVPs (ICMP, BFD) and L2TPv3 control messages.
***CP: Which Name/number space do these belong to?

---

7.1.1. L2TPv3 VCCV ICMP Ping AVP

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

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

***CP: The incoming Session ID provides context to identify the PW.
***CP: However, including only the Remote End ID AVP optionally does not
***CP: catch all problems. It does catch Demux/PW-ID inconsistencies.
***CP: But what if for example the Remote End ID AVP maps to the Session
***CP: ID received, but there is a mismatch in the PW Type? It seems all
***CP: AVPs that define the PW should be included as well (as the "FEC
***CP: 128" TFS in MPLS-PING includes both IP addresses and PW Type).

---

7.1.1. L2TPv3 VCCV ICMP Ping AVP

...

7.1.2. L2TPv3 VCCV BFD AVP

***CP: It seems some guidelines as far as how to respond in some cases
***CP: are missing. For example, what if there is a mismatch between the
***CP: Remote End ID AVP and the Session ID (mismatch in PW/session
***CP: association)? Should it just not reply (as if not received) or
***CP: reply (as in no problem) since there's no granularity to specify
***CP: "Return Codes". Or some other mechanism?

---

7.2.1. L2TPv3 VCCV Capability AVP

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

***CP: The separation between the two fields in the above figure is
***CP: shifted. More importantly though, it would seem it would be
***CP: useful to define CC Type bitmask here as well. Even if there's
***CP: only one CC Type defined in this document (using the L2-Specific
***CP: Sublayer), defining the bitmask and the L2SS bit allows for
***CP: forward-compatibility, if/when new CC Types need to be added.

---

8.1.2. CV Types

       0x04  BFD

***CP: 0x04 was broken down in two in Section 6.1, and that should be
***CP: reflected in IANA section.

---

9. Security Considerations

     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.

***CP: These two paragraph seem from LDP GR.

Thanks,

--Carlos.

Circa 9/28/2005 3:11 AM, Stewart Bryant said the following:
> 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
> 

-- 
--Carlos.
Escalation RTP - cisco Systems

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

---

From: "Mustapha Aissaoui" <[email-masked]>
Date: Tue, 11 Oct 2005 17:23:09 -0400

Here are my comments:
---------
3. Overview of VCCV
...
   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
   reverse direction. If this fails, the operator may use other reply
   modes to determine the fault [LSP-PING].

MA> I guess you are saying make use of Reply Mode 4 - "Reply via application
level control channel". We need to be explicit here.
---------
3. Overview of VCCV
...
   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
   declares that direction of the PW down and it notifies the upstream
   PE. Based on the emulated service, the PEs may send native indica-
   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.

MA> It will help if a reference to draft-ietf-pwe3-oam-msg-map-03.txt is
added. Here is a the proposal for the last sentence:
"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. Details can be found in [OAM-MAP]"
---------
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.

MA> What is the intent in the last sentence? Why include the "user-plane"
control word in the VCCV message?
---------
4.3. TTL Expiry VCCV

MA> Need to be explicit wether the "user plane" control word is included or
not as per comment on Section 4.2.
---------
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.

MA> I guess it will be helpful to indicate that BFD is intended to verify
the datapath only. Here is a proposal:
"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 of the PW datapath and propagation of forward and
reverse defect indications."
---------
5.2. Bidirectional Forwarding Detection
...
   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
   followed.

MA> It will be useful to explicitly state that the BFD session should be
bootstrapped by a LSP-Ping message over the PW, i.e., VCCV-Ping.
---------
5.2. Bidirectional Forwarding Detection
...
   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

MA> codpoint "8 - Reverse Concatenated Path Down" is missing. This is used
in draft-ietf-pwe3-oam-msg-map-03.txt to signal reverse defects in AC or PW.
---------
6. OAM Capability Indication for PWs Demultiplexed using MPLS
...
   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.

MA> This complicates so much the negotiation process for the VCCV
capabilities. The text in an eralier version of this draft stated that the
PE's exchanged the capabilities they supported and then will use only the
common set to both of them. This is inline with the way we negotiate other
PW parameters. Can we please go back to the initial text?
---------
6.1. Optional VCCV Parameter
...
       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.

MA> In fact, type 0x04 still requires the near-end PE (PE1) to send a BFD
message to notify the remote PE of the defect in the PW, even if PE1 sends a
PW status message. This is explained in draft-ietf-pwe3-oam-msg-map-03.txt.
If you did not, then far-end BFD state machine would not know the near-end
timed out.
-----------
7.1.2. L2TPv3 VCCV BFD AVP
...
   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.

MA> But how is a BFD session initialized in the case of a L2TPv3 PSN? Before
sending  the first BFD message, both sides should agree on the discriminator
for each direction and negotiate the rate of the messages.
-----------

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Stewart Bryant
> Sent: Wednesday, September 28, 2005 3:11 AM
> To: pwe3
> Subject: [PWE3] draft-ietf-pwe3-vccv-07.txt - LAST CALL
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 20 Oct 2005 14:30:06 -0400

Responses inline (start with TDN) as I am making these edits to  
the draft.

> level control channel". We need to be explicit here.

     TDN: Done.

> VCCV for these purposes. Details can be found in [OAM-MAP]"

TDN:    OK

> control word in the VCCV message?

     TDN: I think you are looking at an older version of the draft.
          The current version of the draft that is published (-07)
          does not contain that last sentence.

> not as per comment on Section 4.2.

     TDN: Done.

> weight means

     TDN:    Done.

> bootstrapped by a LSP-Ping message over the PW, i.e., VCCV-Ping.

TDN:    There is no need to boot strap the BFD session using
         LSP ping w/ PWs, as the normal P2P BFD bootstrapping
         procedures can be used. I have included "single-hop"
         in the sentence now to be more clear.

> in draft-ietf-pwe3-oam-msg-map-03.txt to signal reverse defects in  

     TDN: Good catch!

> PW parameters. Can we please go back to the initial text?

     TDN:  I understand, and have changed the text.

> If you did not, then far-end BFD state machine would not know the  

     TDN:  Is there any text you feel would clarify?  We did  
reference [OAM-MAP]
             at the end.

     TDN:  I augmented the text as follows:

    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. Normal single-hop
    BFD initialization procedures SHOULD be followed [BFD].

     --Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 20 Oct 2005 14:53:30 -0400

> ***CP: packet, and "application level control channel" (LDP).

TDN:    I modified the introduction text earlier (see last reply) to
         address this.

> ***CP: Should probably clarify sub-TLV of Target FEC Stack TLV.

TDN:    I don't understand what you are asking me to do here.

> Also TFS

TDN:    I modified the text as follows:

    The LSP Ping header must be used as described [LSP-PING] and MUST
    also contain the sub-TLV of 8 for the L2 VPN endpoint or 9 or 10
    for "FEC 128 Pseudowire" or 11 for the "FEC 128 Pseudowire".
    The sub-TLV indicates the PW to be verified.

> ***CP: Should be "in the direction from PE1 to PE2 is  

TDN:  Ok, fixed to:

    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., Diagnostic code 1 - control detection time expired) and
    sends a message to PE1 containing this diagnostic code.
    This causes PE1 to declare the PW in the direction from PE1 to PE2
    is 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].

> ***CP: Redundant "indication".

TDN:    OK.

> ***CP: Should change `interface parameter field' with sub-TLV.

TDN:    OK.

> ***CP: Interface Parameter sub-TLV.

TDN:    OK.

> ***CP: "none, one or more" (instead of "both"), since there's more  

TDN: OK.

> 7.2.1. L2TPv3 VCCV Capability AVP

TDN:    I am going to let Rahul look at the above L2TP questions.

> ***CP: These two paragraph seem from LDP GR.

TDN:    I reworked the text to the following:

      An intruder may impersonate an LDP peer in order to
      force a failure and reconnection of the TCP connection.
      Please see the Security Considerations section of
      [RFC3036] details.

     --Tom

---

From: Carlos Pignataro <[email-masked]>
Date: Thu, 20 Oct 2005 15:08:09 -0400

Tom,

Thanks for the updates. Please see inline.

> TDN:    I don't understand what you are asking me to do here.

I just meant something like:
   The LSP Ping header must be used as described [LSP-PING] and MUST
   also contain a Target FEC Stack in turn containing the sub-TLV ...

Thanks,

--Carlos.

>> ***CP: only one CC Type defined in this document (using the L2- Specific

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 20 Oct 2005 16:37:11 -0400

>    also contain a Target FEC Stack in turn containing the sub-TLV ...

     TDN:    Gotcha. Done!

     --Tom

---

From: Rahul Aggarwal <[email-masked]>
Date: Sun, 23 Oct 2005 16:40:19 -0700 (PDT)

Hi Carlos,

Please see inline:

[snipped]

>***CP: define how to use the `Sequence #' field in the Default L2SS.

The sequence number field is used as defined in [L2TPv3]. Will clarify
this.

> ***CP: Which Name/number space do these belong to?

ICMP Ping AVP and BFD AVP belong to the L2TPv3 AVP number space. Will
clarify this explicitly in the IANA section.

> ***CP: 128" TFS in MPLS-PING includes both IP addresses and PW Type).

Will add the PW Type AVP.

> ***CP: "Return Codes". Or some other mechanism?

This is the same issue as the case when periodic LSP-Ping messages are
used with BFD for BFD over MPLS PWs. If there is a failure in processing
the LSP-Ping message [eg a mismatch between the FEC and the data plane
state], a LSP-Ping error is generated. In the L2TPv3 case a L2TPv3 error
is generated as specified in [L2TPv3].

Text can be added to say:

"L2TPv3 AVPs that identify a PW are processed as defined in [L2TPv3]."

> ***CP: shifted.

ok.

> More importantly though, it would seem it would be

ok.

Thanks for the comments.

rahul

---

From: Carlos Pignataro <[email-masked]>
Date: Mon, 24 Oct 2005 23:43:01 -0400

Hi Rahul,

Thanks for your answers. Please see inline.

> The sequence number field is used as defined in [L2TPv3]. Will clarify

OK. It would also be useful to clarify how specifically, since RFC3931
defines the sequence number field usage for data packets only and based
on the sequencing level signaled with the Data Sequencing AVP. I mean,
for VCCV packets, should sequencing not be used by clearing the S-bit,
or used with a separate sequence number space? Is it dependent upon the
sequencing level signaled for the specific PW as defined in [L2TPv3] (I
don't think it should be)?

> clarify this explicitly in the IANA section.

OK. I think that in addition, this section should clarify the meaning
and usage (or lack of usage) of these AVPs in L2TPv3 "Control Messages"
(over the L2TPv3 the "Control Connection").

> is generated as specified in [L2TPv3].

This part I'm confused. RFC3931 does not specify how to handle/process
these situations. It defines how to handle some of these AVPs within
specific L2TPv3 message types. Do you mean an error is sent using a
result/error code in a Result Code AVP sent in the reply over the VCCV
channel? Part of my confusion may be triggered by the fact that the VCCV
encapsulation for L2TPv3 makes use of a set of AVPs (excluding a message
type - Message Type AVP), in a context outside Control Messages.

For example (it will help me understand), if a VCCV message over L2TPv3
is sent over the VCCV channel with an ICMP Echo AVP, Remote End ID AVP
and PW Type AVP, and the receiving PE detects a mismatch between the FEC
(mismatch with either IP addresses, Remote End ID or PW Type) and the
data plane Session ID: What exactly should that PE reply? Where?

>>***CP: forward-compatibility, if/when new CC Types need to be added.

Thank you for considering them and for the answers.

--Carlos.