Subject: [mpls] AD review of draft-ietf-mpls-tp-ring-protection

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 4 Mar 2013 16:38:52 -0000

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!

---

From: Loa Andersson <[email-masked]>
Date: Tue, 05 Mar 2013 10:14:57 +0100

Adrian,

Thanks for this review I think I'm in the position to answer
the question on the number of authors.

Early 2010 we had 5 or 6 different drafts addressing "mpls-tp-ring-
protection" from one aspect or another. Most of these drafts had
2 or maybe 3 different authors.

The wg chairs took an initiative to discuss the possibilities to
merge all drafts into one. The discussion was partially succesful,
and all draft but one, were merged into a single document. Texts
from all drafts were merged into draft-weingarten-mpls-tp-
ring-protection (later to be adopted as the working group draft
draft-ietf-mpls-tp-ring-protection.

The number of authors on the first page reflect text contributions
made to the drafts that were merged.

/Loa

On 2013-03-04 17:38, Adrian Farrel wrote:
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consult)        phone: +46 739 81 21 64

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 5 Mar 2013 14:42:13 -0000

OK. Thanks for that.

While I still don't understand the fixation with "I have to have my name on the
front page" and while I note that the WG chairs appoint the editors of WG
documents (there is no self-appointment), I will fold what you have written into
the shepherd and AD write-ups in the hope that we can convince the RFC Editor to
relax the rules for this I-D.

Cheers,
Adrian

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: 05 March 2013 09:15
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [mpls] AD review of draft-ietf-mpls-tp-ring-protection
> 
> Adrian,
>