Subject: [PWE3] Comments on draft-ietf-pwe3-vccv-bfd-00

From: Stewart Bryant <[email-masked]>
Date: Thu, 07 Feb 2008 13:43:08 +0000

Tom, Carlos

Sorry this is so late. I started doing the review just before I went
to Seoul, and have only just noticed that I had not finished and sent it.

Stewart

Abstract

   This document describes new Connectivity Verification (CV) types for
   using Bi-directional Forwarding Detection (BFD) with Virtual Circuit
SB> I think you mean "types using"

   The new BFD CV Types are PSN-agnostic, and hence applicable for both
   MPLS and L2TPv3 PSNs.  This document concerns itself with the BFD
   VCCV operation over Single-Segment Pseudowires (SS-PW).

   VCCV can support several Connectivity Verification types (CV types)
   or protocols.  This section defines new CV types for use when BFD is
   used as the VCCV payload.  These types apply to both MPLS and L2TPv3
   Pseudowire demultiplexors.

SB> The above two paras seem to overlap/repeat themselves - you should
SB> think about rephrasing.

   BFD CV Types:

      The defined values for the different BFD CV Types for MPLS and
      L2TPv3 PWs are:

Nadeau & Pignataro        Expires May 12, 2008                  [Page 3]
  <http://tools.ietf.org/html/draft-ietf-pwe3-vccv-bfd-00#page-4>
Internet-Draft                  BFD VCCV                   November 2007

         Bit (Value)    Description
         ============   ==========================================
         Bit 2 (0x04) - BFD for PW Fault Detection Only.
         Bit 3 (0x08) - BFD for PW Fault Detection and AC/PW Fault

SB> Not sure we have the term AC/PW defined

      3.1. BFD CV Type Operation

   When heart-beat indication is necessary for one or more PWs, the
   Bidirectional Forwarding Detection (BFD) [I-D.ietf-bfd-base <http://tools.ietf.org/html/draft-ietf-pwe3-vccv-bfd-00#ref-I-D.ietf-bfd-base>] provides
   a means of continuous monitoring of the PW data path and propagation
   of forward and reverse defect indications.

   In order to use BFD, both ends of the PW connection must have
   signaled the existence of a control channel and the ability to run
   BFD on it (see Section 3.3 <http://tools.ietf.org/html/draft-ietf-pwe3-vccv-bfd-00#section-3.3> and Section 4 <http://tools.ietf.org/html/draft-ietf-pwe3-vccv-bfd-00#section-4>). 

SB> What about static config?

   Once a node has both
   signaled and received signaling from its peer of these capabilities,
   it begins sending BFD control packets.  The packets are sent on the
SB> The BFD packets?

   VCCV control channel.  The use of the control channel provides the

SB> the VCCV control channel?

   When the downstream PE (D-PE) does not receive control messages from

SB> BFD control messages?

      2. BFD Encapsulation

   This document defines two pairs of BFD CV Types (see Section 3 <http://tools.ietf.org/html/draft-ietf-pwe3-vccv-bfd-00#section-3>) which
   specify two ways in which a BFD connectivity verification packet may
   be encapsulated over the VCCV control channel.  Table 1 in
   Section 3.3 <http://tools.ietf.org/html/draft-ietf-pwe3-vccv-bfd-00#section-3.3> summarizes the BFD CV Types.

SB> Do you mean two CV types, each with two methods of encapsulation?

   However, when BFD CV Types of 0x10 or 0x20 are employed, the IP/UDP
   headers are omitted from the BFD encapsulation.  

SB> I think it might be to put this the other way round - to say
SB> what the encap form is, and then to say how it is identified
SB> in the signalling (if used).

   In summary, if a PW Associated Channel Header is used, the Channel
   Type can indicate IPv4 (0x0021) or IPv6 (0x0057) for CV Types 0x04
   and 0x08, or BFD without IP/UDP headers (0x0007) for CV Types 0x10
   and 0x20.

SB> This is a section on encap, surely you just have to say that
SB> ACH MUST be used. Putting the type info here just confuses.
SB> you cover the type mapping later.

      3.3. CV Types for BFD

   Two distinctive pairs of CV Types are defined for BFD.  Table 1
   summarizes the BFD CV Types, grouping them by encapsulation (i.e.,
   with and without IP/UDP headers) and by functionality (i.e., fault
   detection only, or fault detection and status signaling).

Nadeau & Pignataro        Expires May 12, 2008                  [Page 5]
  <http://tools.ietf.org/html/draft-ietf-pwe3-vccv-bfd-00#page-6>
Internet-Draft                  BFD VCCV                   November 2007

   +---------------------+-----------------+---------------------------+
   |                     | Fault Detection |    Fault Detection and    |
   |                     |       Only      |      Status Signaling     |
   +---------------------+-----------------+---------------------------+
   |     BFD with IP/UDP |       0x04      |            0x08           |
   |             Headers |                 |                           |
   |                     |                 |                           |
   |  BFD without IP/UDP |       0x10      |            0x20           |
   |             Headers |                 |                           |
   +---------------------+-----------------+---------------------------+

                 Table 1: Bitmask Values for BFD CV Types

   Given the bidirectional nature of BFD, before selecting a given BFD
   CV Type capability to be used, there MUST be a match in the given CV
   Type capability advertised and received.  That is, only BFD CV Types
   that were both advertised and received are available to be selected.
   Additionally, only one BFD CV Type can be used (selecting a BFD CV
   Type excludes all the remaining BFD CV Types).

   The following list enumerates restrictions and their corollaries on
   the usage of BFD CV Types:

   1.  CV Types 0x08 and 0x20, SHOULD NOT be used when a control
       protocol such as LDP [RFC4447 <http://tools.ietf.org/html/rfc4447>] or L2TPV3 [RFC3931 <http://tools.ietf.org/html/rfc3931>] is available
       that can signal the AC/PW status to the remote endpoint of the
       PW.

       A.  In the case of CV Type 0x08 or 0x20, the AC and PW status is
           conveyed via BFD status codes as specified in
           [I-D.ietf-pwe3-oam-msg-map <http://tools.ietf.org/html/draft-ietf-pwe3-vccv-bfd-00#ref-I-D.ietf-pwe3-oam-msg-map>].

   2.  Similarly, CV Types 0x04 and 0x10 SHOULD NOT be used when there
       is no control protocol available to signal the AC/PW status.

       A.  In the case of type 0x04 or 0x10, BFD is used exclusively to
           detect faults on the PW and the status of those faults are to
           be conveyed using some means other than BFD, such as using
           LDP status messages when using MPLS as a transport (see
           Section 5.4 of [RFC4447] <http://tools.ietf.org/html/rfc4447#section-5.4>), or the Circuit Status AVP in an
           L2TPv3 SLI message for L2TPv3 (see Section 5.4.5 of
           [RFC3931] <http://tools.ietf.org/html/rfc3931#section-5.4.5>).

SB> Would it be better to say the opposite type SHOULD be used rather 
SB> than say it in the negative as SHOULD NOT?

   3.  Only a single BFD CV Type can be seleced and used.

    4. Capability Selection

   As already enumerated, when a control protocol that can signal the
   AC/PW status is not available, CV Types CV Types 0x04 and 0x10 (i.e.,
   for Fault Detection only) SHOULD NOT be used.  When a control
   protocol that can signal the AC/PW status (such as LDP [RFC4447 <http://tools.ietf.org/html/rfc4447>] or
   L2TPv3 [RFC3931 <http://tools.ietf.org/html/rfc3931>]) is available, CV Types 0x08 and 0x20 (i.e., for
   Fault Detection and Status Signaling) SHOULD NOT be used.  All BFD CV
   Types are mutually exclusive with the rest, selecting a BFD CV Type
   prevents the use of any of the other three BFD CV Types.

SB> Again should we say it the other way round?

    9. References

SB> Maybe I missed it but I could not see a protocol definition or a reference
SB> to protocol definition for BFD without UDP/IP

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

---

From: Carlos Pignataro <[email-masked]>
Date: Wed, 13 Feb 2008 16:49:00 -0500

Hi Stewart,

Thank you for your comments, please see inline.

> SB> I think you mean "types using"

Yes, thanks. Same in the Intro.

> SB> think about rephrasing.

OK.

> Internet-Draft                  BFD VCCV                   November 2007

We don't. We can probably point to the terminology and abbreviations
from RFC5085, so that we don't miss any other.

> SB> What about static config?

It's mentioned in RFC5085, but agreed, we need to explicitly mention it
here. For static configs, something along the lines of "both ends need
to be statically provisioned to use the same BFD CV Type".

>    it begins sending BFD control packets.  The packets are sent on the

Yes.

> SB> the VCCV control channel?

Yes.

> SB> BFD control messages?

Yes, thanks.

> SB> Do you mean two CV types, each with two methods of encapsulation?

No, four CV Types; this para is confusing, we can rephrase it.

> SB> in the signalling (if used).

Good point. The paras (2 and 3) should start with encap.

> SB> you cover the type mapping later.

But shouldn't this (the "ACH MUST be used") only apply to the encap
without IP/UDP (i.e., in the previous paragraph)? The text says:

    Therefore, these BFD
    CV Types can only be used when the Pseudowire utilizes a Control Word
    (CW) or Layer-2 Specific Sublayer (L2SS) that can take the PW
    Associated Channel Header (PW-ACH) Control Word format.

We can change that to "Therefore, to utilize this encapsulation, a PW
MUST use a CW...".

As far as listing the channel type values (that identify the pid encap),
I think it's not covered later (only in the IANA section), and seems to
belong as part of the encap. It can be split into the two previous
paragraphs though, and cleaned up.

Related to this, shouldn't we also define a channel type for "BFD Echo"
(being 0x0007 for "BFD Control without IP/UDP" instead of the current 
"BFD without IP/UDP")? This is related to the LC comment:

	Should BFD Echo Mode be explicitly excluded? Should the PW
	Associated Channel Type (Section 5.2) be called "BFD Control
	Packets Without IP/UDP Headers" instead of "BFD Without IP/UDP
	Headers"? Or better should echo be allowed and a channel type
	assigned for it? Any reason why it shouldn't be allowed (given
	that BFD w/o IP/UDP requires a CW/ACH and has a PID)?

> Internet-Draft                  BFD VCCV                   November 2007

I think that (this was pointed out already) this part (item #2 
specifically, and corresponding text in the next section) is
over-specified. There is the implicit assumption that these PWs want to
do status signaling, and might not necessarily be the case generally.
There could be situations in which 0x04/0x10 could be used for static, 
making this requirement is overly-restrictive. This part needs more work.

> SB> Again should we say it the other way round?

Same as above.

> SB> to protocol definition for BFD without UDP/IP

I was thinking of adding a reference to draft-ietf-bfd-generic-04, and a
couple of specific pointers to Section 6 ("data protocol" == the PW) and 
Section 8 ("tunneling and pseudowire protocols"). Is this the type of 
reference you had in mind, would this suffice? Thoughts?

Thanks again,

--Carlos.

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems