Applicability of MPLS Transport Profile for Ring Topologies
draft-ietf-mpls-tp-ring-protection-06

[Ballot comment]
Probably the RFC editors would correct this. Anyway, here it is

"Contributing Authors" section title -> "Contributors"

https://www.rfc-editor.org/rfc-editor/instructions2authors.txt :

      1.  First-page header          [Required]
      2.  Status of this Memo        [Required*]
      3.  Copyright Notice            [Required*]
      4.  IESG Note                  [As requested by IESG*]
      5.  Abstract                    [Required]
      6.  Table of Contents          [Required for large documents]
      7.  Body of the Memo            [Required]
      7a.  Contributors
      7b.  Acknowledgments
      7c.  Security Considerations  [Required]
      7d.  IANA Considerations
      7e.  Appendixes
      7f.  References
      8. Author's Address            [Required]
      9. IPR Boilerplate              [Required*]

[Ballot comment]
- So colour me puzzled - the write up says "nothing new here,
just a way to use 6378" but there are two RAND+fee IPR
declarations. Sigh. (But no more than a sigh since the WG are
ok with it.)

- Is the syntax on p6 for describing label stacks not more
generic than this? I assume its too late (or not worth the
bother) to take this out into its own informational RFC as it
might be more broadly useful. If that text is replicated from
elsewhere then I'd suggest you reference the elsewehere and
not include it here again.

- The tables/figures/whatever between figures 7 and 9 have no
captions.

[Ballot comment]
I don't object to the Informational status of this document, but I have to ask, in a non-blocking and non-confrontational way:

From the shepherd writeup:
  This document does not specify a protocol but describes how to
  use the MPLS-TP linear protection as specified in RFC 6378 for
  ring topologies, the document is thus intended to be published as
  an informational RFC.

This really *is* what applicability statements are for, the title even calls itself an applicability statement, and it does make recommendations (not just give information).  I wonder, then, why it's Informational, rather than Standards Track (see RFC 2026, Section 3.2).

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-mpls-tp-ring-protection-05, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Applicability of MPLS-TP Linear Protection for Ring Topologies) to Informational RFC


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Applicability of MPLS-TP Linear Protection for Ring Topologies'
  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
ietf@ietf.org mailing lists by 2013-04-18. 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

  This document presents an applicability of existing MPLS protection
  mechanisms, both local and end-to-end, to Multi-Protocol Label
  Switching Transport Profile (MPLS-TP) in ring topologies.  This
  document does not propose any new mechanisms or protocols.
  Protection on rings offers a number of opportunities for optimization
  as the protection choices are starkly limited (all traffic traveling
  one way around a ring can only be switched to travel the other way on
  the ring), but also suffers from some complications caused by the
  limitations of the topology.

  Requirements for MPLS-TP protection especially for protection in ring
  topologies are discussed in "Requirements of an MPLS Transport
  Profile" (RFC 5654) and "MPLS Transport Profile (MPLS-TP)
  Survivability Framework" (RFC 6372).  This document shows how MPLS-TP
  linear protection as defined in RFC 6378 can be applied to single
  ring topologies, discusses how most of the requirements are met, and
  describes scenarios in which the function provided by applying linear
  protection in a ring topology falls short of some of the
  requirements.

  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-ring-protection/

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


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1872/

AD review
=====

Hi authors of draft-ietf-mpls-tp-ring-protection,

I have conducted my usual review of your document in response to the
publication request received from the working group.  The purpose of
my review is to find and resolve issues that might otherwise be found
later in the process (IETF last call, IESG review, RFC Editor
processing) and which might slow down the progress of the document or
obscure other issues.

Can I begin by saying that this document is much clearer and better
structured than the version I reviewed some time ago in the working
group. Thanks for all of the work that has gone into it.

Although I found the description of protection for p2mp LSPs became
quite complex, I cannot see a way to make it clearer and more direct.
I suspect it is of the nature of the subject that the material has to
be a bit convoluted. In practice, you have used simple words and a
logical progression, so there is probably nothing further to be done.

I did find a number of fairly small editorial issues and questions
that I would like you to handle before we move on. I will put the
document into "Revised I-D needed" state, but please note that all
of my comments are open for discussion.

Thanks again for the work,
Adrian

---

Why are there eight authors on the front page?
Did all authors contribute equally to the document with some special
reason why they all need to be named on the front page?
If so, I need to understand the circumstances to defend them to the RFC
Editor.
If not, can you please split the list into:
Editors
- appear on the front page
- listed in the Authors' Addresses section
Contributing Authors
- not on the font page
- listed in the Contributors section

---

In Section 1

  This document proposes a set of basic mechanisms that could be used
  for the protection of the data flows that traverse an MPLS-TP ring.
  These mechanisms are based on existing MPLS and MPLS-TP protection
  mechanisms.  These mechanisms provide data flow protection due to any
  switching trigger within a reasonable time frame and optimize the
  criteria set out in [RFC5654], as summarized above.

This seems to contradict the statement in the Abstract that this is an
applicability of linear protection to a ring.

Is this document a description of how you use LP in a ring, or does it
describe new mechanisms? I think the former, in which case this para
should probably read

  This document describes how a set of basic MPLS-TP linear protection
  mechanisms defined in [RFC6378] can be used to provide protection of
  the data flows that traverse an MPLS-TP ring.  These mechanisms
  provide data flow protection in the event of any switching trigger
  within a reasonable time frame and optimize the criteria set out in
  [RFC5654], as summarized above.

Additionally, I believe it would be helpful to state in the Abstract and
in the Introduction that:

  This document defines no new protocol mechanisms or procedures.

---

In Section 1.1, why do bullets 1 and 2 (the first of the so-numbered)
include the possibility of traffic either ending at the egress node or
continuing on beyond the ring, yet not specifically countenance traffic
starting at the ingress node or originating outside the ring?

Is there something special I am missing?

---

In Section 1.1 bullet 3 you have:

  An operator command is issued to a specific ring node.

I think a little more specificity is needed. For example,

  An operator command that changes the operational state of a node or
  a link, or specifically triggers a protection action is issued to a
  specific ring node.

---

Should the last para of 1.1 actually be in 1.2?

---

While Figure 2 can be (and is!) used to explain steering in Section 2.2,
the figure is actually demonstrating SPMEs and as such is confusing. I
think you need an additional figure to explain steering.  It would look
as:

                    ======>/LSR\********/LSR\********/LSR\======>
                          \_B_/########\_A_/########\_F_/
                            *@                      @*
                            *@                      @*
                            *@                      @*
                            _*@          ___          @*_
                          /LSR\********/LSR\********/LSR\
                          \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/

          ===> connected LSP    *** physical link
          ###  working path    @@@ alternate path

                      Figure 2: Steering protection for P2P path

---

Shouldn't Figures 3, 4 and 5 show "connected LSP" for comparison with
other figures?

---

Figure 5 is almost impossible to parse. It is not just the way it is
drawn, but the lack of text that describes the figure using the terms
expressed in the key.

---

Section 2.4 says "(based on a ring with N nodes, assumed to be not more
than 16)"

Is there actually anything in this text that relies on that assumption?
Do the mechanisms have problems for N > 16 ?

---

I am curious as to why the optimisation for wrapping is presented in
Section 3.1 for p2mp flows on the ring, but is not offered as an
option for p2p flows for which it is equally applicable.

---

The text in 3.1 that refers back to "normal" wrapping is suspect.

  This improved mechanism, which we call Ring Optimized Multipoint
  Wrapping (ROM-Wrapping), behaves much the same as classical wrapping.
  There is one difference - rather than configuring the protection LSP
  between the end nodes of a failed link (link protection) or between
  the upstream and downstream node of a failed node (node protection),
  the improved mechanism configures a protection p2mp LSP from the
  upstream (with respect to the failure) node and all egress nodes (for
  the particular LSP) downstream from the failure.

I think that in wrapping in conventional transport networks, the
protection LSP is not configured in the way you say. Instead, it exists
as a complete ring. Only when a fault is detected (effectively breaking
the protection ring) is the protection LSP terminated at the edges of
the fault.

Maybe your text is intending to talk about SPMEs? Maybe this back-
reference is actually not necessary in this section that should describe
what ROM-Wrapping does, not what it doesn't do.

---

In section 3.1 you have introduced a new notation to indicate the
ring-exits on the LSP. This is fine but:
- you don't explain it
- the notation conflicts with that which you carefully introduced for
  label stacks.

---

Figure 7 is included in Section 3.2 but not referenced until 3.2.1.
Should it be moved?

---

In 3.2.1 please expand LIB

---

Section 8 is a bit weak :-)
I suppose there were too many people to list individually!