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

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 16 Aug 2012 12:21:17 +0100

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.

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.

Please work with the chairs and the working group to resolve these
issues.

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."

---

Please fix the format nits shown by idnits (page and line lengths).

---

Per the exchanges on the MPLS mailing list, you need to replace "PHP as
optional" with "PHP must be disabled by default"

---

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

---

The Table of Contents is a bit messed up.

---

There are a number of random page throws that mess up the formatting.

---

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.

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).

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).

- - - -

Abstract

OLD
   The
   design considerations discussed in this documents ranging from
NEW
   The
   design considerations discussed in this document range from

- - - -

Section 1.1

OLD
The end of live for many
NEW
The end of life for many

- - - -

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

- - - -

Section 1.1

OLD
   MPLS-TP extended current MPLS OAM
   functions
NEW
   MPLS-TP extended previous MPLS OAM
   functions

---

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.

---

There are too many acronyms used in Section 1 without expansion.

---

Section 1.2

I think Henry Yu asked for you to change his affiliation.

---

s/2. Terminologies/2. Terminology/

---

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.

Please also decide whether G-ACH or 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.

- - - -

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.

- - - -

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.

---

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.

---

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?

---

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.

Where does Section 1.2 sit with respect to the Authors and
Contributors? Do you really need Section 1.2?

---

s/10.     Author's Addresses/10.     Authors' Addresses/

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Thu, 16 Aug 2012 15:18:23 +0000

Adrian,

Thank you very much for your AD review and comments, appreciate your effort to help identify the issues in details.
We'll revise the document to address all comments and work with chairs and working group to resolve all issues.

Thanks,
Luyuan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Adrian Farrel
> Sent: Thursday, August 16, 2012 7:21 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [mpls] AD review of draft-ietf-mpls-tp-use-cases-and-design
> 
> Hi,
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls