Requirements of an MPLS Transport Profile
draft-ietf-mpls-tp-requirements-10

[Ballot comment]
Agree with many of Dan's points.

Section 1., paragraph 13:
>    MPLS-TP will enable the depoyment of packet based transport networks

  Nit: s/depoyment/deployment/


Section 2, paragraph 0:
>    2  Any new functionality that is defined to fulfill the requirements
>        for MPLS-TP MUST be agreed within the IETF through the IETF
>        consensus process as per [RFC4929]

  Agree with Dan - this isn't a requirement on the technology, it's a
  meta-requirement.


Section 29, paragraph 0:
>    29  MPLS-TP MUST be able to scale at least as well as existing
>        transport technologies with growing and increasingly complex
>        network topologies as well as with increasing bandwidth demands,
>        number of customers, and number of services.

  It will be impossible to verify if this requirement is met. (This
  comment applies to all other scaling requirements in the document.)


Section 65, paragraph 0:
>    65  MPLS-TP protection mechanisms MUST support revertive and non-

  Nit: s/revertive/reverting/ (And what does this mean?)


Section 66, paragraph 0:
>    66  MPLS-TP MUST support 1+1 protection.

  Where is "1+1 protection" defined?


Section 68, paragraph 0:
>    68  MPLS-TP MUST support 1:n protection (including 1:1 protection).

  Where is "1:n protection" defined. (And is "1:1 protection" different
  from "1+1 protection"?)

[Ballot discuss]
1. A very key paragraph in the Introduction defines the scope of the document:

  This document specifies the requirements of an MPLS Transport Profile
  (MPLS-TP).  The requirements are for the behavior of the protocol
  mechanisms and procedures that constitute building blocks out of
  which the MPLS transport profile is constructed.  That is, the
  requirements indicate what features are to be available in the MPLS
  toolkit for use by MPLS-TP.  The requirements in this document do not
  describe what functions an MPLS-TP implementation supports.  The
  purpose of this document is to identify the toolkit and any new
  protocol work that is required.

I have a very basic question - what is the 'MPLS toolkit' which is refered here? Are we talking about the various standards-track documents that define MPLS and its extensions? Is there another document that defines this?

2. Section 2 in its first paragraph further clarifies the scope of the requirements as:

  The requirements are for the behavior of the protocol
  mechanisms and procedures that constitute building blocks out of
  which the MPLS transport profile is constructed.  That is, the
  requirements indicate what features are to be available in the MPLS
  toolkit for use by MPLS-TP.

Whatever the 'toolkit' means, if the requirements are on protocol mechanisms and procedures, than I do not believe that requirement #2 must be listed as a requirement here.

2  Any new functionality that is defined to fulfill the requirements
      for MPLS-TP MUST be agreed within the IETF through the IETF
      consensus process as per [RFC4929]

This is a process requirement, and it should be listed separatly, maybe in the introduction section.

3. 

17  MPLS-TP MUST support the physical separation of the control and
      management planes from the data plane.

Does this requirement mean that the data plane must be on a separate physical network that the control and management planes? In this case why do we need the following:

  115  Guaranteed resources for in-band control and management plane
        traffic regardless of the amount of data plane traffic.

4. I am also a hard time understanding the following requirement:

  23  MPLS-TP MUST support the capability for network operation
      (including OAM and recovery) via the management plane (without
      the use of any control plane protocols).

If I write a management plane solution for MPLS-TP what do I need to do? Make sure that network operations like OAM and recovery can be performed by using the management protocols and entities, or just make sure that the management plane protocvols can configure and monitor OAM and recovery operations?

5.

2.5, 2.6, 2.7 refer to the mpls-tp-oam-requirements and to the mpls-tp-nm-req documents. However, these are Informational References for this document. Maybe it would be better for the three sections to be taken out of what seem to be the normative text section and the fact that the set of requirements for MPLS-TP has other companion documents should be mentioned separetly for informational purposes.

6. In Section 2.8.3

75  MPLS-TP MUST support physical layer fault indication triggers.

Do we really mean only physical layer, or also link layer? An 802.3 MAC indication or an 802.17 ring fault for example would not be covered by 'physical layer indication triggers'.

[Ballot discuss]
1. A very key paragraph in the Introduction defines the scope of the document:

  This document specifies the requirements of an MPLS Transport Profile
  (MPLS-TP).  The requirements are for the behavior of the protocol
  mechanisms and procedures that constitute building blocks out of
  which the MPLS transport profile is constructed.  That is, the
  requirements indicate what features are to be available in the MPLS
  toolkit for use by MPLS-TP.  The requirements in this document do not
  describe what functions an MPLS-TP implementation supports.  The
  purpose of this document is to identify the toolkit and any new
  protocol work that is required.

I have a very basic question - what is the 'MPLS toolkit' which is refered here? Are we talking about the various standards-track documents that define MPLS and its extensions? Is there another document that defines this?

2. Section 2 in its first paragraph further clarifies the scope of the requirements as:

  The requirements are for the behavior of the protocol
  mechanisms and procedures that constitute building blocks out of
  which the MPLS transport profile is constructed.  That is, the
  requirements indicate what features are to be available in the MPLS
  toolkit for use by MPLS-TP.

Whatever the 'toolkit' means, if the requirements are on protocol mechanisms and procedures, than I do not believe that requirement #2 must be listed as a requirement here.

2  Any new functionality that is defined to fulfill the requirements
      for MPLS-TP MUST be agreed within the IETF through the IETF
      consensus process as per [RFC4929]

This is a process requirement, and it should be listed separatly, maybe in the introduction section.

3. 

17  MPLS-TP MUST support the physical separation of the control and
      management planes from the data plane.

Does this requirement mean that the data plane must be on a separate physical network that the control and management planes? In this case why do we need the following:

  115  Guaranteed resources for in-band control and management plane
        traffic regardless of the amount of data plane traffic.

4. I am also a hard time understanding the following requirement:

  23  MPLS-TP MUST support the capability for network operation
      (including OAM and recovery) via the management plane (without
      the use of any control plane protocols).

If I write a management plane solution for MPLS-TP what do I need to do? Make sure that network operations like OAM and recovery can be performed by using the management protocols and entities, or just make sure that the management plane protocvols can configure and monitor OAM and recovery operations?

5.

2.5, 2.6, 2.7 refer to the mpls-tp-oam-requirements and to the mpls-tp-nm-req documents. However, these are Informational References for this document. Maybe it would be better for the three sections to be taken out of what seem to be the normative text section and the fact that the set of requirements for MPLS-TP has other companion documents should be mentioned separetly for informational purposes.

6. In Section 2.8.3

75  MPLS-TP MUST support physical layer fault indication triggers.

Do we really mean only physical layer, or also link layer? An 802.3 MAC indication or an 802.17 ring fault for example would not be covered by 'physical layer indication triggers'.

7. Section 2.9

  113  Support of services, which are sensitive to jitter and delay.

What does 'Support' mean in this context? The previous requirement for example speaks about badwidth:

  112  Enabling the provisioning and the guarantee of Service Level
        Specifications (SLS), with support for hard and relative end-to-
        end bandwidth guaranteed.

Are similar guaranteed services envisioned for jitter and delay? how? if not what is exactly required? only provisioning? maybe only monitoring?

Note that this document is a requirement document, for reasons that have
to do with referencibility by ITU-T we have opted to put it on the
standards track. The same decision applies to all MPLS-TP requirement
documents.

MPLS-TP Requirements
draft-ietf-mpls-tp-requirements-09

are published as an IETF stream RFC on the Standards Track.




    (1.a) Who is the Document Shepherd for this document? Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

          Loa Andersson is the document shepherd.

    (1.b) Has the document had adequate review both from key WG members
          and from key non-WG members? Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

          The document is very well reviewed, by the mpls, ccamp, pwe3
          and l2vpn working groups, as well as the mpls-tp ad hoc team
          team at the ITU-T and SG15 of the ITU-T. The SG15 has sent a
          liaison stating the approval of the document.

    (1.c) Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

          no

    (1.d) Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of? For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it. In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here. Has an IPR disclosure related to this document
          been filed? If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

          no

    (1.e) How solid is the WG consensus behind this document? Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

          very solid

    (1.f) Has anyone threatened an appeal or otherwise indicated extreme
          discontent? If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director. (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

          no

    (1.g) Has the Document Shepherd personally verified that the
          document satisfies all ID nits? (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/). Boilerplate checks are
          not enough; this check needs to be thorough. Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

          yes - the nits tool says that the document lack the 2119
          boiler plate. The boiler plate is there but is preceded by
          a few words explaining why we use normative language in a
          requiremetns document. This might be what casuses the problem.


    (1.h) Has the document split its references into normative and
          informative? Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state? If such normative references exist, what is the
          strategy for their completion? Are there normative references
          that are downward references, as described in [RFC3967]? If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

          the references are split into normative and informative
          references

    (1.i) Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document? If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries? Are the IANA registries clearly identified? If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations? Does it suggest a
          reasonable name for the new registry? See [RFC5226]. If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

          The IANA considerations section exists, but there are no
          requests for IANA allocations.

    (1.j) Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

          The documents is text document written in plain ascii.

    (1.k) The IESG approval announcement includes a Document
          Announcement Write-Up. Please provide such a Document
          Announcement Write-Up? Recent examples can be found in the
          "Action" announcements for approved documents. The approval
          announcement contains the following sections:

          Technical Summary
              Relevant content can frequently be found in the abstract
              and/or introduction of the document. If not, this may be
              an indication that there are deficiencies in the abstract
              or introduction.

    This document specifies the requirements of an MPLS Transport Profile
    (MPLS-TP).  This document is a product of a joint International
    Telecommunications Union (ITU)-IETF effort to include an MPLS
    Transport Profile within the IETF MPLS and PWE3 architectures to
    support the capabilities and functionalities of a packet transport
    network as defined by International Telecommunications Union -
    Telecommunications Standardization Sector (ITU-T).

    This work is based on two sources of requirements; MPLS and PWE3
    architectures as defined by IETF, and packet transport networks as
    defined by ITU-T.

    The requirements expressed in this document are for the behavior of
    the protocol mechanisms and procedures that constitute building
    blocks out of which the MPLS transport profile is constructed.  The
    requirements are not implementation requirements.


          Comment:
          This document is a requirement document, for reasons that has
          to do with referencibility by ITU-T we have opted to put it
          on the standards track. The same decision applies to all
          mpls-tp requirement documents.

          Working Group Summary
              Was there anything in WG process that is worth noting? For
              example, was there controversy about particular points or
              were there decisions where the consensus was particularly
              rough?

          No controversies, but lots of discussion that has converged on
          this document.

          Document Quality
              Are there existing implementations of the protocol? Have a
              significant number of vendors indicated their plan to
              implement the specification? Are there any reviewers that
              merit special mention as having done a thorough review,
              e.g., one that resulted in important changes or a
              conclusion that the document had no substantive issues? If
              there was a MIB Doctor, Media Type or other expert review,
              what was its course (briefly)? In the case of a Media Type
              review, on what date was the request posted?

          This is a requirements document, implementations will follow
          when we have the protocol specifications.