Hello,

I have been selected as the Routing Directorate reviewer for this
draft. The Routing Directorate seeks to review all routing or
routing-related drafts as they pass through IETF last call and IESG
review, and sometimes on special request. The purpose of the review is
to provide assistance to the Routing ADs. For more information about the
Routing Directorate, please see
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF
Last Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-mpls-smp-requirements-06.txt
Reviewer: Lou Berger
Review Date: June 21 2014
IETF LC End Date: 2014-06-23
Intended Status: Informational

Summary:
    I have some minor concerns about this document that I think
    should  (must, actually) be resolved before publication.

Comments:

    I think the document is well written and, other than a couple of
    terminology related issues, easily understood.  The document does
    have a number of terminology and technical issues which should be
    readily resolved prior to publication.

Major Issues:

    Major issues are the type of concerns that will result in the
    document being blocked until they are resolved. The Routing ADs will
    become involved.  Please include all of the major issues you have
    found. Give as much context information as possible (e.g., section
    numbers, paragraph counts).  If you find no major issues, please
    write: "No major issues found."

- No major issues found.  In particular, I expect all issues can be
  resolved without AD intervention.  Some of the minor issues, if not
  resolved will be escalated to the AD/major issue category.

Minor Issues:

    Minor issues are concerns about clarity or technical accuracy that
    should be discussed and resolved before publication, but which would
    normally be resolved between the authors and the reviewers.  Please
    include all of the minor issues you have found. Give as much context
    information as possible (e.g., section numbers, paragraph counts).
    If you find no minor issues, please write: "No minor issues found."

- Document's usage of "committed" vs "allocated" resources:

  In section 1 the document introduces the notion that the
  distinction between protection and restoration is based on when
  resources are "committed".  This difference from past
  definition. RFC4427 and 6372 make the distinction that protection
  and restoration differ based on when resources are *allocated* not
  *committed*.  To quote RFC 4427:

    The distinction between protection and restoration is made based
    on the resource allocation done during the recovery LSP/span
    establishment.  The distinction between different types of
    restoration is made based on the level of route computation,
    signaling, and resource allocation during the restoration
    LSP/span establishment.

  This difference also leads to come confused statements in the
  document as well as ambiguity in the text, i.e. confusion by the
  reader.  The term "committed" is not tightly defined in this
  document (or earlier work) and is used differently than how
  "allocated" has been used. An example of this can be found in
  Section 3.1 which states:

     However, the commitment of the resources, at least for the
     shared segments, will only be finalized when the protection
     path is actually activated.  Therefore, for the purists -
     regarding the terminology - SMP lies somewhere between
     protection and restoration.

  Both sentences are problematic. In the first, commitment seems to
  cover a "protection switch" would "connect" the protection path
  but not the earlier "allocation" of resources. (Quoted terms are
  used in earlier RFCs.)  The second conclusion is based on the new
  distinction of protection vs. restoration and is unnecessary with
  the existing distinction.

  This issue exists in multiple places in the document where
  "committed" is used and I'd recommend that each should be replaced
  with terminology used in the referenced RFCs, i.e., "allocation",
  "connection", "cross-connect", "protection switch(over)", ...

  Note I'm *not* highlighting all cases where there are problems in the
  document related to this issue.  There are a couple of places in the
  document where I think it's possible that once this terminology
  ambiguity is corrected that I'll have other substantive comments.

- Section 2, 1st paragraph, last sentence.  This sentence really defines
  the scope/purpose of the document, i.e., "clarifies the instructions
  to protocol designers producing solutions that satisfy the
  requirements set out in this document."  As such, I'd repeat this in
  the abstract and move it to a more pronounced place in section 1 (or
  3).

- General comment: fate-sharing for co-routed bidirectional LSP
  protection: How is co-routing preserved for the reverse path in SMP?
  I'd assumed the protection switch coordination protocol would be
  required to trigger a switchover of the reverse LSP in the co-routed
  case, but don't see this in the document.

- In section 4 and 5.2 you reference 5712 and 3209 as defining
  preemption terminology and behavior.  I think 6372 is the right
  reference here as it defines both in the context of survivability and
  in dependent of control plane.

- In section 4.2 you say "Therefore, it is suggested that this be
  carried out under the control of a dynamic control plane similar to
  GMPLS [RFC3945]."  perhaps you mean "based on GMPLS"?  If so, great,
  please make the correction.  If not, I think the debate of which
  control protocol is used for MPLS-TP is way beyond the scope of this
  document.

- Section 5.1, paragraph 1. Why are you using "SHOULD NOT" here?  If
  referring to solutions conformant with this document, then these are
  informative statements, "and a non-control plane based SMP switchover
  mechanism is used, the control plane SHALL NOT ...". If referring to
  an operator's/user's choice of protection mechanism, I think the most
  you can say is MAY.

- Section 5.2. "Tie-breaking rules SHALL be defined in scope of an SMP
  domain."  As this is a requirement, what you mean by "tie-breaking
  rules" should be defined directly or by reference.

- Section 5.3. RFC6372 takes an approach where preemption notification
  leverages the standard MPLS-TP OAM mechanisms, is there any reason to
  do more / not just follow 6372?

- Section 5.7.  There may be coordination required on soft-preemption as
  well (depending on the cross-connects established during LSP
  establishment) so coordinated switching should be supported
  independent of preemption mode.

Nits:

- Abstract: I don't recall the term "executive action" being used in any
  earlier related/referenced RFCs.  Rather than introduce a new (and
  undefined) term, perhaps you can use an existing one, e.g.,
  "protection switch"?

- Section 1, paragraph 1.  Do we really need another definition of
  MPLS-TP to debate?  I suggest just referencing your favorite MPLS-TP
  document(s) and dropping the first four sentences.

  The last sentence also makes a subjective statement.  Whether it is
  critical or no is unnecessary.  You can just say something like 6372
  provides a survivability framework for MPLS-TP and is the foundation
  for this document.

- Section 1, paragraph 3. Isn't the right reference 4427 not 4428?
  Also drop the word linear, as it is an unnecessary qualifier and
  4427/4428 don't use it.

- Sections 3 (and to a lesser degree section 2) are really introductory
  text.  I'm unsure as to why they aren't part of section 1.

- Section 3.2 should have a reference for "existing control plane
  solutions for SMP within MPLS".

- Section 3.2 again uses the "executive action" term.

- Section 4.1. You say "two operations simultaneously".  Do you really
  mean "simultaneously" or merely that they must both occur for
  protection to be provided? (Same comment in section 5.1.

- Section 5.2. I suggest numbering the currently bulletted requirements
  list.

- Section 5.2: First paragraph and forth bullet last sentence.  These
  both basically cover the same topic (preemption) and actually say
  slightly different things.  I suggest combine into a single
  requirement to ensure consistency and full coverage of the topic.

- Section 5.2, req 5.  How does this relate to section 5.5?  Shouldn't
  the topics related to timing be consolidated?

- Section 5.2: requirement 6 seems to be a subset of 7, so it should be
  dropped.

- Section 5.2, requirement 8. Isn't this a subset of 9?  Why call out
  just this one traffic treatment (sub) requirement?

- Section 5.3. s/MAY/will

- section 5.4: " When the working path detects.." detection is by the
  node not the path.

- Section 5.4, last sentence.  This is only the 2nd time you imply that
  the document covers requirements on a new protocol.  I think this
  point is currently too subtle in the document.  (This point was also
  made as a minor comment.)

- section 5.6. RFC 6372 should be referenced