ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-mpls-tp-rosetta-stone-12.txt> (A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations.) to Informational RFC

2013-10-17 06:15:22
Reviewer: Abdussalam Baryun (AB)
I-D name: draft-ietf-mpls-tp-rosetta-stone-12
Date: 17.10.2013
Reply to IETF LC message dated 02.10.2013
+++++++++++++++++++++++++++++++++

Overall Review:
The reviewer decision is that the I-D is not ready to be publish
because it does not achieve clearly its aim and objectives and subject
to additional information and structure. This thesaurus is difficult
to trace and gather information related to MPLS, even though it is
informational draft. This draft's terminology section is not done in a
methodology similar to RFC4397 in terms of showing separate resources
in each subsection and relating to the document aim. The title seems
like the terminology of both documentations are made as thesaurus, but
when we go into the I-D the reviewer feels it is not organised as a
thesaurus to simplify search and relating terms or issues of MPLS-TP.
There are many terminology not clear but more general definition. I
prefer specific defining to clarify to ALL Internet-Community not only
specific readers (otherwise should mention that it is not for ALL
community to understand). Also many times refers to references to
define without mentioning what was that definition, is that defined
only in ITU? is there an agreement that some one defines parts and
other org defines other parts? why IETF draft cannot define its
technology developed MPLS-TP? or is this draft agreeing on a joint
definitions of many documents without clear methodology or IETF is
just following ITU in some terms? The answers to these questions are
very important to make the thesaurus easy to trace.

Draft methodology of definition and terminology:
The way the draft starts a definition should not be refering to a
reference, this makes the reader leave the document and distracted,
and does not know where to go which page in such reference. In ITU-T
documents we find more organised which it defines and then refers to
the location of such definition but not the page which the reviewer
prefers in such situation. Therefore, it is better for an IETF
partcipant to understand the context and even get thesaurus-of-terms
when going through the some ITU-T documents (e.g. ITU-T G.8101/Y1355
(10/12) ) better than this ietf-draft, which means the IESG needs to
compare between this draft and ITU-T way of representing terms and
defining them, to make a better draft representation facing other
organisations, otherwise, people stop using this draft in future.

AB>Question to authors>
Who is the reader: is this document only designed for IETF familiar
RFCs readers or if someone from ITU refered by one document wants to
read this doc could he/she understand? (please note that ITU does
refer people to this draft as this draft is defining some terms and
they acknowledge).
In the reviewer's opinion it should mention this issue or who can read
or what are the documents that should be read, because it was
mentioned that this I-D is for IETF to get the ITU context.

I-D> Scope and Applicability:
++++++++++++++++++++
AB> The scope is not clear because in the draft says:-

I-D>page 2> in Abstract>
This document provides a thesaurus for the interpretation of MPLS-TP
terminology within the context of the ITU-T Transport Network
recommendations.

I-D>page 4> in Introduction>
This document provides a thesaurus for the interpretation of ITU-T
Transport Network terminology within the context of the MPLS-TP.

I-D>page 17> Section 4>
As discussed in the introduction to this document, this thesaurus is
intended to bring the concepts and terms associated with MPLS-TP
into the context of the ITU-T’s Transport Network architecture.

AB> The above objectives are not consistent scoped or not explained
how and which context and terms are related and interpreted. The
methodology of doing both is not clear, or even how they relate within
the draft. The reviewer thinks there may be an editorial mistake, but
still the scope was confused by that because terms were referenced to
both RFCs and ITU-Gs.

AB> suggest adding> The motivation of the scope is nice to mention as
done in RFC4397. However, it is easier to write scope/motivation of
RFC4397 but not this draft because we want our participants to be
familiar with other organisation's documents or concepts. I hope we
don't loose our participants to go work for ITU and stop participating
in our IETF :-)

I-D> page 4> This document provides a thesaurus for the interpretation of ITU-T
Transport Network terminology within the context of the MPLS-TP.
This allows MPLS-TP documents to be generally understood by those
familiar with MPLS RFCs.
AB>not clear why it allows understanding> the reviewer thinks that the
draft's thesaurus does show pointers to ITU documents but does not
deliver the specific definitions of thoes terminologies within the ITU
nor within Transport Network context.

AB> to strengthen the scope of the draft to make both ITU and IETF
participant work on similar terminologies> Add info:
In past ITU-T developed extensions to MPLS developed by IETF to
address the requirements of the transport network (T-MPLS). However,
concerns were raised by the IETF that the approach taken by the ITU-T
was incompatible with widely deployed - MPLS - technology. Now both
ITU and IETF have work together to set a next generation transport
network technologies compatible with MPLS-TP.

AB> Question> Is there a discussion with the ITU Group responsible
about defining terms, because in one document of theirs they mention
something like some terms listed defined by IETF and some listed
defined by ITU-T? (yes it is mentioned in acknowledgement about ITU
and designe team, but not reflected or shown in the document scope).
Why is there different in concepts between MPLS-TP and the ITU
Transport Network, if the MPLS-TP was developed to facilitate
technologies within ITU transport Network context?

AB> Questions> Are the ITU documents under normative referencing the
last documents as up to date? and what are the affects of amendment of
ITU documents are they like our RFCs. Therefore, the reviewer request
all normative to be in force documents and  including any amendments
if related to this I-D.

AB> suggest> Some documents of amendments are related but not
referenced, such as amendments to ITU-T G.8101/Y1355 as [ITU-T
G.8101/Y1355 (10/12)] in 2012. Please consider adding and refering to
it.


I-D> Introduction Section>
+++++++++++++++++++
I-D>Multiprotocol Label Switching - Transport Profile (MPLS-TP) has been
   developed by the IETF to facilitate the Operation, Administration
   and Management of Label Switched Paths (LSPs) in a Transport Network
   environment as defined by the ITU-T.

AB> the MPLS-TP is defined by IETF not by ITU-T, so prefer to make it
clear in the paragraph. It can be understood: the IETF developed it as
defined by ITU-T.

AB> amend to:
Multiprotocol Label Switching - Transport Profile (MPLS-TP) has been
   developed and defined by the IETF to facilitate the Operation, Administration
   and Management of Label Switched Paths (LSPs) for interoperability
in a Transport Network environment as defined by the ITU-T.

AB> please add>
MPLS-TP is a connection-oriented packet-switched transport layer
network technology, is a profile of the MPLS that supports deployment
in transport networks and allows operations in a manner consistent
with other transport technologies.

AB> add> please mention that this definition of MPLS-TP by IETF will
allow consistent with other transport technologies defined by ITU-T.

AB>In Section 1.2> please explain or add info:
In the document there are many abbreviations as CC, CE, ME, etc., but
not mentioned if these abbreviations are used in ITU-T as a common
abbreviation or are not, the IETF participant would like to know such
information in this thesaurus. Also the section prefered to say this
is the documents abbreviation (e.g. wondering why some have abbrv and
others have not within the thesaurus).

Why authors used CC why not CCh as in other RFC? or does the CC has
been used in the ITU? please clarify why.

AB> suggest> CC to be changed to MPLS-TP Comm Channel (MTCC) and also
all others related terms.

AB> some words are not clear related to terminologies and MPLS and ITU
concepts. As there are words not defined but abbreviated as: Network
Element (NE). Other words not defined as : Channel, path, point,
connection, .etc. The reviewer wants to know it under the context of
MPLS-TP and Transport Network concept as the draft aims to do but not
found by reviewer.

In ITU documents in abbreviation section, it mentions as this
recommendation abbreviation, this draft needs to mention that this is
its abbreviation as well.

Please refer to below editor abbreviation in section 2:
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt

The draft makes in its first page an abbreviation of IETF even though
it is mentioned in the webpage above of RFC editor.

AB>no consistency> The ITU-T has no abbreviation but still document
mentions the IETF abbreviation while the IETF is our organisation and
ITU is not and both are in RFC editor as no need abbreviation. Also
MPLS is similar abbreviated in the document and the editor signals it
as known, but in document mentioned more than one time. The ITU
documents mentions the ITU abbreviation.

I-D>Page 1>
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF)

AB> the document uses the word * see * to refer to document that has
the definition, but not refers to pages that has the definition. I
prefer not to refer, because this is a thesaurus so it is better to
explain with words and refer in the end of sentence as for example
pointing page in ref as [ITU-T_G.806, p4].

I-D> Section 2> Terminology:
++++++++++++++++++++
AB>Discuss>
Section 2 needs an introduction, the reader does not know what is the
document terminology, we have two organisations IETF and ITU, two
sources of terminology and concepts that this document is considering
but it seems that is not clear mentioned in the section in details.
For example, Is the terms in the thesaurus taken from ITU documents or
from IETF? or both? and then are they defined in the context of ITU-T
or of Transport Network?

AB> the sections 2.1 and 2.2 has references that are repeated in 2-3
which is confusing because it was thought that these sections show
distinction where references are for MPLS-TP terms and others for  ITU
and others references having common terms. Please clarify and
rephrase.

I-D>Section 3> Thesaurus:
++++++++++++++++++

AB>The section needs an introduction to explain these terms and their
relationships, I get confused when I see a thesaurus terms without
good relationship based on a model or methodology. It seems that the
draft is more referencing where are definitions than giving a clear
thesaurus and guidance/interpretation.

The concept of Transport Network should be defined, and also the
MPLS-TP concept.

The Network Elements are defined in ITU with deep specification but in
this draft seems general, also in ITU-T it related NE as in concept
MPLS-TP Network Element (MT.NE), why this is not reflected in this
draft.

This I-D's name is mentioned in the reference [ITU-T G.8101/Y1355
(10/12)], and that ITU reference is not mentioned in this I-D, why.
The [ITU-T G.8101/Y1355 (10/12)] explains better than this I-D that
there are definitions defined in this I-D and there are definition
defined by ITU documents and they list them all. Why does this I-D not
explain in similar clarifications to readers to distinguish and avoid
conflict in understandnings.

I-D> 3.1  Associated bidirectional path:
AB>Question> how can a path defined as a path without mentioning its
between what and through what? this is not specific definition, but
general, or too general.

I-D> 3.2 Bidirectional path:
AB>Question> how can a path defined as a path without mentioning its
between what and through what? this is not specific definition, but
general, or too general.
How does it differ from the 3.1 definition?

I-D> 3.3 Client layer network:
AB> it is a network but not defined under the MPLS-TP concept, to show
what is these layers or layer-network, and not distinguished from the
server layer network, please clarify.

I-D> 3.4 Communication Channel
AB> what is this channel? it cannot be defined as a path, as you say
between NEs, the reviewer thinks a channel is bandwidth of the
communication path. You must relate the channel to the path or paths
and connections, etc. This section is very poor in information
delivering.

I-D>3.6 Control Plane:
AB> not defined, and the reviewer though we are looking into MPLS-TP
under ITU-T context not the scope of RFC5654, please rephrase.

AB> In general> The above are examples of confusion not all
confusions. In the opinion of the reviewer that the definitions and
thesaurus is week represented to easily find the specific definition
related to draft objectives.

****Nits*****

AB> Question> the I-D uses words differently *end point* and
*endpoint* why? please amend to consistentancy. Relate it in the draft
interpretation to *connection point*, and/or NEs.

I-D> customer’s (individual or bundled)
AB> amend to : customer’s (i.e. individual or bundled)

AB> RFC3031 wrong title and not complete authors>amend reference in
sec 9.1 to:

[RFC3031]  Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol
Label Switching Architecture", January, 2000.

AB> RFC5654 not complete authors>amend reference in sec 9.1 to:

[RFC5645]  Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and Ueno, S., "Requirements of an MPLS Transport Profile", September,
2009.

AB> RFC5860 not in order authors and title not same>amend reference in
sec 9.1 to:

[RFC5860] Vigoureux, M., Ward, D., and Betts, M., "Requirements for
Operations, Administration, and Maintenance (OAM) in MPLS Transport
Networks", May, 2010.

AB> RFC5860 not complete authors>amend reference in sec 9.1 to:

[RFC5921] Bocci, M., Frost, D., Bryant, S., Levrau, L., and Berger,
L., "A Framework for MPLS in Transport Networks", July, 2010.

AB> RFC5951 not complete authors and wrong title>amend reference in
sec 9.1 to:

[RFC5951] Lam, K., Gray, E., and Mansfield, S., "Network Management
Requirements for MPLS-based Transport Networks", September 2010.

++++++++++  The End ++++++++++

Sorry for the delay,

Best Regards
AB

On 10/2/13, The IESG <iesg-secretary(_at_)ietf(_dot_)org> wrote:

The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'A Thesaurus for the Terminology used in Multiprotocol Label Switching
   Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport
   Network Recommendations.'
  <draft-ietf-mpls-tp-rosetta-stone-12.txt> 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(_at_)ietf(_dot_)org mailing lists by 2013-10-16. Exceptionally, comments 
may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   MPLS-TP is based on a profile of the MPLS and PW procedures as
   specified in the MPLS-TE and (MS-)PW architectures developed by the
   IETF.  The ITU-T has specified a Transport Network architecture.

   This document provides a thesaurus for the interpretation of MPLS-TP
   terminology within the context of the ITU-T Transport Network
   recommendations.

   It is important to note that MPLS-TP is applicable in a wider set of
   contexts than just Transport Networks.  The definitions presented in
   this document do not provide exclusive nor complete interpretations
   of MPLS-TP concepts.  This document simply allows the MPLS-TP terms
   to be applied within the Transport Network context.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-rosetta-stone/

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


No IPR declarations have been submitted directly on this I-D.


<Prev in Thread] Current Thread [Next in Thread>
  • Re: Last Call: <draft-ietf-mpls-tp-rosetta-stone-12.txt> (A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations.) to Informational RFC, Abdussalam Baryun <=