MPLS Transport Profile (MPLS-TP) Linear Protection
draft-ietf-mpls-tp-linear-protection-09

[Ballot comment]
The first part of the discuss was fixed - thanks.

Adrian now owes me a beer for not explaining something
or other to do with this draft and the 2nd part of my discuss
in Quebec - given that I'm sure he's right and I get a beer,
I've cleared :-)

[Ballot comment]
1. In Section 3.1:

OAM indication - OAM fault management or performance measurement 
      tools may detect a failure or degrade condition on either the   
      working or protection transport path and this must input an 
      indication to the Local Request Logic.

better s/must/MUST/

2. In Section 4.1:

      The actual frequencies used may be 
      configurable, at the time of establishment, for each individual 
      protected LSP.  For management purposes, the operator should be able 
      to retrieve the current default frequency values as well as the 
      actual values for any specific LSP.

In the first sentence better s/may/MAY/
In the second sentence better s/should/SHOULD/

[Ballot comment]
1. In Section 3.1:

OAM indication - OAM fault management or performance measurement 
      tools may detect a failure or degrade condition on either the   
      working or protection transport path and this must input an 
      indication to the Local Request Logic.

better s/must/MUST/

2. In Section 4.1:

      The actual frequencies used may be 
      configurable, at the time of establishment, for each individual 
      protected LSP.  For management purposes, the operator should be able 
      to retrieve the current default frequency values as well as the 
      actual values for any specific LSP.

In the first sentence better s/may/MAY/
In the second sentence better s/should/SHOULD/

3.

[Ballot discuss]
This is an updated discuss (hoping I just missed this)

#1) cleared

#2) cleared

#3) cleared

#4) RFC 5586 says that the ACH is in network byte order, but doesn't say anything about the encoding for ACH TLVs.  Maybe this draft should explicitly state that the TLV is encoded in network byte order (or is this stated somewhere else in the MPLS suite of RFC+drafts)?

[Ballot discuss]
(1) I can't find section 4.7 of [SurvivFwk] which is
where you promise a definition of linear protection.
Suggest fixing the ref but also adding at least a
short description.

(2) I didn't have time to follow all the references
from the security considerations (sorry). Do those
provide a way to authenticate the messages from this
protocol so as to prevent a bad actor from switching
traffic to somewhere they want to monitor or somewhere
with less capacity (as part of a Dos)?

[Ballot comment]
#1) Section 1.1: r/compared to other survivability mechanisms/, compared to other survivability mechanisms (e.g., ... ).

Isn't it kind of an empty claim otherwise?  The survivability draft only claims:

  In a mesh network, linear protection
  provides a very suitable protection mechanism because it can operate
  between any pair of points within the network.

#2) Expand P2P on first use.

#3) In Section 4.2.2, I think it would aid the reader greatly to add a pointer to registry in Section 5.2?  When I read 4.2.2, the first thought that popped in to my mind was: well what about all the other values are they reserved?  It's probably also worth point out that values are assigned by IANA.

[Ballot discuss]
Some more from the obviously uninformed reader...

#1) Section 4.2.2, I thought this section would also say something along the lines of "other values are ignored by this version of the protocol".

#2) Section 4.2.5 & 4.2.6: Shouldn't there be a registry for FPath and Path values?

#3) In Section 4.2.7, should it also say that the reserved fields "MUST be ignored on receipt"?

#4) RFC 5586 says that the ACH is in network byte order, but doesn't say anything about the encoding for ACH TLVs.  Maybe this draft should explicitly state that the TLV is encoded in network byte order (or is this stated somewhere else in the MPLS suite of RFC+drafts)?

[Ballot discuss]
The DISCUSS and COMMENT is partially based on the OPS-DIR review performed by Bert Wijnen:

1. in section 3.1:


  o  OAM indication - OAM fault management or performance measurement
      tools may detect a failure or degrade condition on either the
      working or protection transport path and this SHOULD input an
      indication to the Local Request Logic.

Why is this only a SHOULD and not a MUST? If there are exception cases I suggest to detail them.

2. Same question about the next bullet:

o  WTR expires - The Wait-to-Restore timer is used in conjunction
      with recovery from failure conditions on the working path in
      revertive mode.  The timer SHALL signal the PSC control process
      when it expires and the end point SHOULD revert to the normal
      transmission of the user data traffic.

3. in section 4.1:

    The frequency of the three rapid messages and the separate frequency
    of the continual transmission SHOULD be configurable by the operator.
    For protection switching within 50ms, it is RECOMMENDED that the
    default interval of the first three PSC messages SHOULD be no larger
    than 3.3ms.  The subsequent messages SHOULD be continuously
    transmitted with an interval of 5 seconds.

It might be good to explain the rationale for the RECOMMENDED intervals and maybe some explanation as to what considerations need to be taken into account when configuring these values. Has the WG considered to standardize the configurability of these frequencies? Or is it left (intentionally?) to each implementation how this is done?
Can an operator (or an NMS) easily see what the values are at the various LERs?

4. In section 4.3.3.1 and 4.3.3,2 the description of the transitions of the Normal State and Unavailable State end by 'All other local inputs SHALL be ignored.' and 'All other remote messages SHALL be ignored'. In 4.3.3.3 'Protecting administrative state' we have 'All other local inputs SHALL be ignored.' but 'All other remote messages SHOULD be ignored.' In 4.3.3.4.  Protecting failure state, 4.3.3.5.  Wait-to-restore state, and 4.3.3.6.  Do-not-revert state the lists of transitions end with 'All other local inputs SHOULD be ignored.' and 'All other remote messages SHOULD be ignored.' Why SHOULD and not SHALL, what are the exception cases and the recommended behavior?

IANA understands that, upon approval of this document, there are two
IANA actions which must be completed.

First, in the Pseudowire Associated Channel Types Registry located in
the Pseudowire Name Spaces located at:

http://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xml

a new registration will be added as follows:

Value Description TLV Follows Reference
----- ----------------------- ----------- ---------------
0xHH Protection State no [this document]
Coordination Protocol -
Channel Type (PSC-CT)

Second, IANA will create a new registry in the Multiprotocol Label
Switching Architecture (MPLS) Identifier Types registry located at:

http://www.iana.org/assignments/mpls-id-type/mpls-id-type.xml

as follows:

Registry name: "MPLS PSC Request Registry"
Registration procedure: Standards action
Values: the field is four bits in length
Reference: [ RFC-to-be ]

The initial registrations in this new registry are as follows:

Value Description Reference
------------- --------------------- ---------------
b0000 No Request [ RFC-to-be ]
b0001 Do not revert [ RFC-to-be ]
b0010 - b0011 Unassigned
b0100 Wait to restore [ RFC-to-be ]
b0101 Manual switch [ RFC-to-be ]
b0110 Unassigned
b0111 Signal Degrade [ RFC-to-be ]
b1000 - b1001 Unassigned
b1010 Signal Fail [ RFC-to-be ]
b1011 Unassigned
b1100 Forced switch [ RFC-to-be ]
b1101 Unassigned
b1110 Lockout of protection [ RFC-to-be ]
b1111 Unassigned

IANA understands that these are the only actions required to be
completed upon approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (MPLS-TP Linear Protection) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'MPLS-TP Linear Protection'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-07-05. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The Transport Profile for Multiprotocol Label Switching (MPLS-TP) is
  being specified jointly by IETF and ITU-T.  This document addresses
  the functionality described in the MPLS-TP Survivability Framework
  document [SurvivFwk] and defines a protocol that may be used to
  fulfill the function of the Protection State Coordination for linear
  protection, as described in that document.

  This document is a product of a joint Internet Engineering Task Force
  (IETF) / International Telecommunications Union Telecommunications
  Standardization Sector (ITU-T) effort to include an MPLS Transport
  Profile within the IETF MPLS and PWE3 architectures to support the
  capabilities and functionalities of a packet transport network as
  defined by the ITU-T.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-linear-protection/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-linear-protection/


No IPR declarations have been submitted directly on this I-D.

PROTO writeup for  draft-ietf-mpls-tp-linear-protection-07.txt

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Ross Callon is the Document Shepherd. He has reviewed the document and believes that it is ready to be forwarded to the IESG for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

The document has been extensively reviewed by MPLS WG experts as well as by ITU-T. The document has been updated to reflect the comments received and an email summarizing the status of last call comments has been posted to the MPLS WG email list.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No concerns. The review has been very thorough.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of?

No concerns.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 
Consensus is solid. This document describes mechanisms that are quite important for MPLS-TP networks.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?
No.


  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/).

It passes IDnits with 0 errors, and 4 warnings (for example there are 3 outdated references – the references will need to be updated immediately prior to final publication in any case).

  (1.h) Has the document split its references into normative and
        informative?

References are split. Both normative references are RFCs, one (RFC2119) is a BCP, the other is standards track.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document?

IANA section exists, and looks correct to the document shepherd.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

Not applicable (no formal language used)

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

Technical Summary

  The Transport Profile for Multiprotocol Label Switching (MPLS-TP) is
  being specified jointly by IETF and ITU-T.  This document addresses
  the functionality described in the MPLS-TP Survivability Framework
  document  and defines a protocol that may be used to fulfill the
  function of the Protection State Coordination for linear protection.

  Linear protection provides rapid and simple protection
  switching.  In a mesh network, linear protection provides a very
  suitable protection mechanism because it can operate between any pair
  of points within the network.  It can protect against a defect in an
  intermediate node, a span, a transport path segment, or an end-to-end
  transport path.

Working Group Summary

  This document has been carefully reviewed by the MPLS WG as well as by ITU-T. A summary
  of the resolution of the many comments received has been posted to the MPLS WG email list.

Document Quality

  Multiple implementations are in progress.