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

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 11 Oct 2012 12:09:27 +0100

Authors, Chairs, and Working Group,

How should I interpret the progress (or lack thereof) with this draft?

Thanks,
Adrian

> -----Original Message-----
> From: Luyuan Fang (lufang) [mailto:[email-masked]]
> Sent: 16 August 2012 16:18
> To: [email-masked]; draft-ietf-mpls-tp-use-cases-and-
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [mpls] AD review of draft-ietf-mpls-tp-use-cases-and-design
> 
> 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,
> >
> > 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/
> >
> > _______________________________________________
> > mpls mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Thu, 11 Oct 2012 16:08:23 +0000

Hi Adrian,

Nabil and I have discussed this after reviewed your comments. Major
re-write is certainly needed based on your comments.
We are working it, but not gone far yet. Our plan is to complete the
update by the cut-off date.
Given the changes are quite major, we would like to discuss with you
before finishing the updateŠ and certainly work with the chairs on it.

Thanks,
Luyuan