Subject: [PWE3] Shepherd's review of draft-ietf-pwe3-mpls-tp-cv-adv-01

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 22 Oct 2013 16:31:47 -0400

Greg,

As document shepherd for draft-ietf-pwe3-mpls-tp-cv-adv, I did a WG last
call review and have some comments. The good news is that the draft is
mostly in good shape for publication, it just needs a quick revision to
address the comments below. Also, there were no other WG last call comments
which need to be addressed.

First of all, there are some idnits issues that need to be addressed:

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The document doesn't use any RFC 2119 keywords, yet seems to have RFC
     2119 boilerplate text.

  -- The document date (September 20, 2013) is 32 days in the past.  Is this
     intentional?

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Unused Reference: 'RFC5882' is defined on line 270, but no explicit
     reference was found in the text

  -- Obsolete informational reference (is this intentional?): RFC 2434
     (Obsoleted by RFC 5226)

I also have some comments of my own, which are mostly editorial in nature.
They are embedded in the text below. Just do an update to address the nits
and these comments, and I'll be able to forward the draft for publication.

Thanks,
Andy

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

1.  Introduction

   Proactive Connectivity Verification (CV), Continuity Check (CC), and
   Remote Defect Indication (RDI) for the MPLS Transport Profile
   [RFC6428] are applicable to all constructs of the MPLS-TP, including
   pseudowires (PWs).  If Control Plane is used to operate and manage PW
s/Control Plane/a control plane/
s/PW/PWs/
   then procedure defined in [RFC5085] and [RFC5885] should be used to
s/procedure/the procedures/
   select proper type of Control Channel and corresponding type of
   Connectivity Verification.  This document specifies how signaling and
   selection process modified to ensure backward compatibility and allow
s/process modified/processes are modified/
   use of proactive CV-CC-RDI over MPLS-TP PWs.

1.1.  Conventions used in this document

1.1.1.  Terminology

   BFD: Bidirectional Forwarding Detection

   CC: Continuity Check

   CV: Connectivity Verification

   PE: Provider Edge

   VCCV: Virtual Circuit Connectivity Verification

   VCCV CC: VCCV Control Channel

1.1.2.  Requirements Language

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

2.  MPLS-TP CC-CV on Pseudowires

   PW VCCV can support several CV Types.  Ability to support arbitrary
s/Types.  Ability to support/Types, and can support/
   combination of CV modes advertised in CV Types field of VCCV
s/in CV/in the CV/
   Interface Parameter sub-TLV [RFC4446], [RFC4447].  Currently six
   types of CV been defined for PW VCCV out of eight bit long field.
s/VCCV out of eight bit long field/VCCV/
   This document introduces four new CV types and, to accommodate them,
   a new VCCV Extended CV parameter for PW Interface Parameters Sub-TLV
   is defined.

Mirsky                   Expires March 24, 2014                 [Page 3]

Internet-Draft               VCCV MPLS-TP CV              September 2013

2.1.  VCCV Extended CV Advertisement sub-TLV

   The format of VCCV Extended CV Advertisement is a TLV where:

    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Type = 0x19 |    Length     |   CV Type    |   Reserved     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 1: VCCV Extended CV parameter format

   Length - the length of the sub-TLV, including type and the Length
s/Length -/The Length field is/
   field itself.  Minimum length is 4.  It it isrecommended that
s/Minimum/The minimum/
   extensions to the sub-TLV be done in 4 bytes increments with Reserved
   field being set to zero on transmit and ignored on receipt.

   Reserved field must be set to zeroes on transmit and ignored on
   receive.
s/Reserved/The Reserved/

   CV Type field is a bitmask that lists types of CV monitoring that a
s/CV Type/The CV Type/
   PE is capable to support.  VCCV Extended CV parameter sub-TLV must
s/VCCV/The VCCV/
   appear in combination with VCCV parameter sub-TLV.  If VCCV parameter
s/VCCV/the VCCV/ (twice in this line)
   sub-TLV is missing then VCCV Extended CV parameter sub-TLV should be
s/VCCV/the VCCV/
   ignored.

2.2.  MPLS-TP CC-CV Types

   The [RFC6428] defines coordinated and independent modes of monitoring
S/The //
   point-to-point bi-directional connection that can be applied to
   monitoring PWs.  At the same time [RFC6310] defines how BFD-based OAM
   can map and be mapped to status of an Attachment Circuit.  Thus there
   could be four MPLS-TP CV types as combination of modes and
   functionality:

   +---------------+-------------------+-------------------------------+
   |     Modes     |  Fault Detection  |   Fault Detection and Status  |
   |               |        Only       |           Signalling          |
   +---------------+-------------------+-------------------------------+
   |  Independent  |        0x01       |              0x02             |
   |      Mode     |                   |                               |
   |  Coordinated  |        0x04       |              0x08             |
   |      Mode     |                   |                               |
   +---------------+-------------------+-------------------------------+

               Table 1: Bitmask Values for MPLS-TP CV Types

Mirsky                   Expires March 24, 2014                 [Page 4]

Internet-Draft               VCCV MPLS-TP CV              September 2013

2.3.  MPLS-TP CC-CV Type Operation

   Connectivity verification according to [RFC6428] is part of MPLS-TP
   CC/CV operation that can be used with VCCV Control Channel Type 1
   [RFC5085] .  If VCCV CC Type 1 selected, then PEs might select one of
   MPLS-TP CC-CV types as VCCV CV mechanism to be used for this PW.

2.4.  CV Type Selection

   CV selection rules that have been defined in Section 7 of [RFC5085]
   and updated Section 4 of [RFC5885] are augmented in this document.

   If VCCV Control Channel Type 1 is chosen according to Section 7
   [RFC5085] and common set of proactive CV types advertized by both PEs
   includes MPLS-TP CC-CV types and some BFD CV types, then MPLS-TP
   CC-CV takes precedence over any type of BFD CV.  If multiple MPLS-TP
   CV types advertised by both PEs, then following list sorted in
   descending priority order is used:

   1.  0x08 - coordinated mode for PW Fault Detection and AC/PW Fault
       Status Signaling

   2.  0x04 - coordinated mode for PW Fault Detection only

   3.  0x02 - independent mode for PW Fault Detection and AC/PW Fault
       Status Signaling

   4.  0x01 - independent mode for PW Fault Detection only

3.  IANA Considerations

   The PW Interface Parameters Sub-TLV registry defined in [RFC4446].
s/registry defined/registry is defined/

   IANA is requested to reserve a new PW Interface Parameters Sub-TLV
   type as follows:

   +-------------+--------+----------------------------+---------------+
   |  Parameter  | Length |         Description        | Reference     |
   |      ID     |        |                            |               |
   +-------------+--------+----------------------------+---------------+
   |     0x19    | 4      | VCCV Extended CV Parameter | This document |
   +-------------+--------+----------------------------+---------------+

               Table 2: New PW Interface Parameters Sub-TLV

Mirsky                   Expires March 24, 2014                 [Page 5]

Internet-Draft               VCCV MPLS-TP CV              September 2013

3.1.  VCCV Extended CV Types

   IANA is requested to set up a registry of ?VCCV Extended CV Types?.
s/?// (twice)
   These are 8 bitfield values.  Extended CV Type values 0x01, 0x02,
s/bitfield/bit/
   0x04 and 0x08 are specified in Section 2.2 of this document.  The
   remaining bitfield values (0x10 through 0x80) are to be assigned by
s/bitfield//
   IANA using the "IETF Consensus" policy defined in [RFC2434].  A VCCV
   Extended Control Verification Type description and a reference to an
   RFC approved by the IESG are required for any assignment from this
   registry.

   +--------------+----------------------------------------------------+
   |  Bit(Value)  | Description                                        |
   +--------------+----------------------------------------------------+
   | Bit 0 (0x01) | Independent mode for PW Fault Detection only       |
   | Bit 1 (0x02) | Independent mode for PW Fault Detection and AC/PW  |
   |              | Fault Status Signaling                             |
   | Bit 2 (0x04) | Coordinated mode for PW Fault Detection only       |
   | Bit 3 (0x08) | Coordinated mode for PW Fault Detection and AC/PW  |
   |              | Fault Status Signaling                             |
   | Bit 4 (0x10) | Reserved                                           |
   | Bit 5 (0x20) | Reserved                                           |
   | Bit 6 (0x40) | Reserved                                           |
   | Bit 7 (0x80) | Reserved                                           |
   +--------------+----------------------------------------------------+

            Table 3: MPLS Connectivity Verification (CV) Types

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 25 Oct 2013 21:05:40 +0000

Dear Andy,
thank you for your comments and suggestions. All are accepted and I'll make appropriate changes to publish the next version as soon as gate gets open.

                Regards,
                                Greg

From: Andrew G. Malis [mailto:[email-masked]]
Sent: Tuesday, October 22, 2013 1:32 PM
To: Gregory Mirsky
Cc: [email-masked]
Subject: Shepherd's review of draft-ietf-pwe3-mpls-tp-cv-adv-01

Greg,
As document shepherd for draft-ietf-pwe3-mpls-tp-cv-adv, I did a WG last call review and have some comments. The good news is that the draft is mostly in good shape for publication, it just needs a quick revision to address the comments below. Also, there were no other WG last call comments which need to be addressed.
First of all, there are some idnits issues that need to be addressed:

  Miscellaneous warnings:

     2119 boilerplate text.

     intentional?

     (Obsoleted by RFC 5226)
I also have some comments of my own, which are mostly editorial in nature. They are embedded in the text below. Just do an update to address the nits and these comments, and I'll be able to forward the draft for publication.

Thanks,
Andy

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

1.  Introduction

1.1.1.  Terminology

   CC: Continuity Check

   PE: Provider Edge

    0                   1                   2                   3

2.2.  MPLS-TP CC-CV Types

2.4.  CV Type Selection

3.  IANA Considerations

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 25 Oct 2013 17:18:14 -0400

Greg,

Thanks, much appreciated.

Cheers,
Andy

On Fri, Oct 25, 2013 at 5:05 PM, Gregory Mirsky <[email-masked]
> wrote:

>  Dear Andy,****
>
> thank you for your comments and suggestions. All are accepted and I’ll
> make appropriate changes to publish the next version as soon as gate gets
> open.****
>
> ** **
>
>                 Regards,****
>
>                                 Greg****
>
> ** **
>
> *From:* Andrew G. Malis [mailto:[email-masked]]
> *Sent:* Tuesday, October 22, 2013 1:32 PM
> *To:* Gregory Mirsky
> *Cc:* [email-masked]
> *Subject:* Shepherd's review of draft-ietf-pwe3-mpls-tp-cv-adv-01****
>
> ** **
>
> Greg,****
>
> which need to be addressed.****
>
> First of all, there are some idnits issues that need to be addressed:****
>
>   Miscellaneous warnings:****
>
>   ----------------------------------------------------------------------------****
>
> ** **
>
>   == The document doesn't use any RFC 2119 keywords, yet seems to have RFC****
>
>      2119 boilerplate text.****
>
> ** **
>
>   -- The document date (September 20, 2013) is 32 days in the past.  Is this****
>
>      intentional?****
>
> ** **
>
> ** **
>
>   Checking references for intended status: Proposed Standard****
>
>   ----------------------------------------------------------------------------****
>
> ** **
>
>      (See RFCs 3967 and 4897 for information about using normative references****
>
>      to lower-maturity documents in RFCs)****
>
> ** **
>
>   == Unused Reference: 'RFC5882' is defined on line 270, but no explicit****
>
>      reference was found in the text****
>
> ** **
>
>   -- Obsolete informational reference (is this intentional?): RFC 2434****
>
>      (Obsoleted by RFC 5226)****
>
>  I also have some comments of my own, which are mostly editorial in
> nature. They are embedded in the text below. Just do an update to address
> the nits and these comments, and I'll be able to forward the draft for
> publication.
>
> Thanks,
> Andy
>
> ------------
>
> 1.  Introduction
>
> ****