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

["Andrew G. Malis" <[e-mail]>]

Greg,

Thanks, much appreciated.

Cheers,
Andy


On Fri, Oct 25, 2013 at 5:05 PM, Gregory Mirsky <[e-mail]
> 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:[e-mail]]
> *Sent:* Tuesday, October 22, 2013 1:32 PM
> *To:* Gregory Mirsky
> *Cc:* [e-mail]
> *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:****
>
>   ----------------------------------------------------------------------------****
>
> ** **
>
>   == 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
>
>
> ****
>