Subject: [mpls] Last Call: <draft-ietf-mpls-smp-requirements-05.txt> (Requirements for MPLS-TP Shared Mesh Protection) to Informational RFC

From: The IESG <[email-masked]>
Date: Mon, 09 Jun 2014 07:10:11 -0700

The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Requirements for MPLS-TP Shared Mesh Protection'
  <draft-ietf-mpls-smp-requirements-05.txt> as Informational RFC

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
[email-masked] mailing lists by 2014-06-23. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document presents the basic network objectives for the behavior
   of shared mesh protection (SMP) which are not based on control plane
   support. This is an expansion of the basic requirements presented in
   RFC 5654 "Requirements for the Transport Profile of MPLS" and RFC
   6372 "MPLS Transport Profile (MPLS-TP) Survivability Framework".
   This document is to be used as a basis for the definition of any
   mechanism that would be used to implement SMP for MPLS-TP data paths,
   in networks that delegate executive action for resiliency to the data
   plane.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-smp-requirements/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-smp-requirements/ballot/

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 9 Jun 2014 15:26:37 +0100

Here are some comments from my review as AD that need to get handled as part of
IETF last call.

Thanks,
Adrian

===

Could you expand "p2p" where it is first used?

---

The very first sentence is hard to parse

   MPLS transport networks can be characterized as being a network of
   connections between nodes within a mesh of nodes and the links
   between them. 

Maybe try

   The MPLS Transport Profile (MPLS-TP) provides tools to construct and
   operate a set of connections between nodes in an MPLS network.  The
   MPLS network is a mesh comprising nodes and the links between them.

---

I understand that you want to use RFC 2119 language to clarify the 
requirements, but RFC 2119 was developed for specifying protocols, so 
the direct reference and boilerplate quote is incongruous. I suggest
you use the language as found in RFC 5654, viz.:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].
   Although this document is not a protocol specification, the use of
   this language clarifies the instructions to protocol designers
   producing solutions that satisfy the requirements set out in this
   document.

---

In Section 5.1 you have

   the control
   protocol SHOULD NOT be used as the primary resilience mechanism.

I agree, but I think that the term "primary resilience mechanism" may be
under defined. Can you do anything to clarify this? Maybe...

   the control
   protocol SHOULD NOT be used as the primary mechanism for detecting or
   reporting network failures, or for initiating or coordinating 
   protection switch-over.  That is, it SHOULD NOT be used as the 
   primary resilience mechanism.

> -----Original Message-----
> From: mpls [mailto:[email-masked]] On Behalf Of The IESG
> Sent: 09 June 2014 15:10
> To: IETF-Announce
> Cc: [email-masked]
> Subject: [mpls] Last Call: <draft-ietf-mpls-smp-requirements-05.txt>
> (Requirements for MPLS-TP Shared Mesh Protection) to Informational RFC
> 
> [email-masked] mailing lists by 2014-06-23.