Subject: [mpls] AD review of draft-ietf-mpls-tp-use-cases-and-design

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Mon, 17 Dec 2012 09:30:01 +0000

Hi Adrian,

Thanks again for your review. Your comments are extremely helpful for us to improve the quality of this document.
We addressed all your comments and reworked the entire document to tidy it up. Version 03 reflects most changes, 04 has the latest update.
http://tools.ietf.org/html/draft-ietf-mpls-tp-use-cases-and-design-04.
Please see my comments in-line.

-----Original Message-----
To: <[email-masked]<mailto:[email-masked]>>
Subject: [mpls] AD review of draft-ietf-mpls-tp-use-cases-and-design
From: "Adrian Farrel" <[email-masked]<mailto:[email-masked]>>
Date: Thu, 16 Aug 2012 12:21:17 +0100
Cc: [email-masked]<mailto:[email-masked]>

Hi,

I have done my AD review of this document as usual before pushing it
forward for IETF last call and IESG review. This has generated a long
list of comments. Many are formatting and style issues that really
should be fixed to make the document acceptable for publication. Others
are technical questions that need to be resolved either in discussion
or by updates to the document.
#LF: We have updated the document to address all your comments, the latest version is draft-ietf-mpls-tp-use-cases-and-design-04.txt.

The volume of changes will make for quite a bit of extra work, I'm
afraid. But I think these changes are necessary before I can support
this document for publication as an RFC.
#LF: Agree that the changes are necessary, we have done significant editing to update the document, your comments are very very helpful, thanks.

Please work with the chairs and the working group to resolve these
issues.
#LF: Thanks to the chairs for their support and help. And thanks to the WG members for your review/comments in advance.

Thanks,
Adrian
===

In reading the document I find the authors are confused about what they
mean by MPLS-TP. Is MPLS-TP a profile of the MPLS toolset for use in
transport networks? Is it a profile of the MPLS functions that are used
in transport networks? Is it a delta to the base MPLS functions? Is it
a project to enhance the base MPLS to add features needed for transport
networks.

This question results in significant ambiguity in the text. For example,
you say "MPLS-TP disallowed ECMP", but I think you mean that "ECMP is
not appropriate in a transport network, so the MPLS transport profile
assumes that ECMP will not be present and the MPLS tools necessary for
handling ECMP will not be used."
#LF: Fixed in the new version through rewriting.
---

Please fix the format nits shown by idnits (page and line lengths).
#LF: Fixed. The 04 version is nits free as shown by idnits tool.
---

Per the exchanges on the MPLS mailing list, you need to replace "PHP as
optional" with "PHP must be disabled by default"
#LF: Fixed. The text was in Section 3, Section 3 is now removed.
---

It would significantly help the reviewers if you could manage to
format the page headers and footers, align the section headings.
#LF: Done.
---

The Table of Contents is a bit messed up.
#LF: Fixed.
---

There are a number of random page throws that mess up the formatting.
#LF: Fixed.
---

This document desperately needs review by a native speaker to tidy the
English. While this might not seem critical, the large number of small
errors make reading and reviewing hard. They may also obscure some
technical issues.
#LF: Fixed, tidied the language and improved the clarity.

I strongly suggest that the chairs solicit a review from an interested
working group member (in return for a mention in the Acknowledgements,
or in exchange for beer).
#LF: Appreciate WG members to help to review and comment. Acknowledgements and/or beer work for me, great idea.

Here are a few examples from early in the document...
- - - -

Abstract

OLD
   for Multiprotocol Label Switching Transport
   profile (MPLS-TP).
NEW
   for the Multiprotocol Label Switching Transport
   Profile (MPLS-TP).
#LF: Fixed.
- - - -

Abstract

OLD
   The
   design considerations discussed in this documents ranging from
NEW
   The
   design considerations discussed in this document range from
#LF: Fixed, this sentence is removed in the new version.
- - - -

Section 1.1

OLD
The end of live for many
NEW
The end of life for many
#LF: Fixed.
- - - -

Section 1.1

OLD
   MPLS-TP re-use a subset of
   MPLS base functions
NEW
   MPLS-TP re-uses a subset of
   MPLS base functions
#LF: Fixed.
- - - -

Section 1.1

OLD
   MPLS-TP extended current MPLS OAM
   functions
NEW
   MPLS-TP extended previous MPLS OAM
   functions
#LF: Fixed.
---

Why do you consider use of RFC 2119 language to be appropriate in this
Informational document? All I could find was an instance of "MUST" that
you have inherited from RFC 5654. I think you could usefully tidy this
up.
#LF: Removed “Requirements Language” paragraph and the reference to RFC 2119.
---
There are too many acronyms used in Section 1 without expansion.
#LF: Wrote a new list of terminology, included all acronyms which were used in the document.
---

Section 1.2

I think Henry Yu asked for you to change his affiliation.
#LF: Fixed. Section 1.2 is removed. Henry’s correct address is listed in the Contributors' addresses section.
---

s/2. Terminologies/2. Terminology/
#LF: Done.
---

Please clean up Section 2 to remove those acronyms not actually used in
the document. For example, APS, DM, SRLG. You'll need to do a search and
destroy operation. On the other hand, please search the document for
other acronyms such as MSTP.
#LF: Done, wrote a new terminology list.

Please also decide whether G-ACH or G-ACh.
#LF: Done, used G-ACh.
---

Section 3 seems a bit of a muddle. Details below, but this discussion
makes me wonder what the purpose of Section 3 is. The function of
MPLS-TP is well-defined in other documents. By summarising it here you
risk leaving out key pieces, and may give the wrong impression about the
details. It may be better to cut out this section and leave the document
to focus on the uses cases and network design.
#LF: Agree. It is better to remove Section 3, done.
- - - -

Section 3.2

   MPLS-TP extended the LSP support from unidirectional to both bi-
   directional unidirectional support.

The implication here is that there is something different in the MPLS
data plane in MPLS-TP to support bidirectional LSPs. But I don't think
there is. As far as the data plane is concerned, there is no difference
between two unidirectional LSPs and one bidirectional LSP.
#LF: Fixed, removed Section 3.
- - - -

Section 3.3

I don't think that the use of an NMS for static provisioning is a
"control plane option". Maybe if you retitled the section as
"Provisioning". But anyway, I don't see why the ACH is mentioned in
this section.
#LF: Fixed, removed Section 3.
---

The whole of the substantial Section 5.7 amounts to "In MPLS-TP, it is
best to provision LSPs with low or zero Relative Delay Time. But there
is no discussion of what this means for an MPLS-TP deployment.

Furthermore the section ends with...

   More discussion will be added on how to manage the Relative delay
   time.

...and this does not convince me that the document is complete.
#LF: Rewrote section 5.7.
---

Section 6

I would expect this document to examine the security requirements of the
different use cases. When is it necessary to use the security tools
developed and discussed in the two referenced documents?
#LF: Added security discussion on Metro Access and Mobile backhaul use cases, and some general security risks unique to MPLS-TP discussed in the TP Security FW .
---

Could you please split the Authors' Addresses into two sections.
Authors' Addresses to match those on the front page, and
Contributors' Addresses to capture all the others.
#LF: Done.

Where does Section 1.2 sit with respect to the Authors and
Contributors? Do you really need Section 1.2?
#LF: No. Removed Section 1.2.
---

s/10.     Author's Addresses/10.     Authors' Addresses/
#LF: Done.

Thank you!
Luyuan