Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)
draft-ietf-ccamp-gmpls-mln-reqs-11

[Ballot comment]
Section 5.10 comes short from providing enough information on manageability requirements and operational considerations. Although one important aspect of the specific management model is well observed (the need to corelate between the various layers of OAM and management protocols) there is no definition on the operational models (are the management entities located per layer, or admin domains? do admin domains cross layers?) and what kind of management operations could be performed by the refered MIB modules or OAM protocols.

[Ballot comment]
Section 5.10 comes short from providing enough information on manageability requirements and operational considerations. Although one important aspect of the specific management model is well observed (the need to corelate between the various layers of OAM and management protocols) there is no definition on the operational models (are the management entities located per layer or admin domains?) and what kind of management operations could be performed by the refered MIB modules or OAM protocols.

[Ballot comment]
While it is obvious from the Table of Contents, it would be helpful if the Introduction
noted that sections 3 and 4 provide background and the requirements are all captured
in section 5.

I am a little concerned about unstated requirements.  There are very few MUST statements
in section 5 (and some of them are MUST NOTs).  For example, section 5.7 has a number
of MAY statements but no clear requirements.  (Section 3.2.1 of mln-eval implies that
support for multi-region signaling was the requirement.)

I would encourage the authors to review section 5 to ensure that the important requirements
are clearly highlighted.

Note that this is consistent with Jari's discuss, which I support.

[Ballot discuss]
There is no reference in the docuemnt to the operational and manageability requirements of MR and ML networks. I would have expected at a minimum a reference to the operational model, and to the extensions to the MIB modules and OAM techniques needed to operate and manage MRN/MLNs.

[Ballot discuss]
Section 5.4 says:

  Creation, deletion, and modification of LSPs MAY be triggered by
  adjacent layers or through operational actions to meet traffic
  demand changes, topology changes, signaling requests from the upper
  layer, and network failures.

I am very surprised to learn that LSP modification per operational actions
is just a MAY.

Section 5.7 says:

  Path computation MAY take into account LSP region and layer
  boundaries when computing a path for an LSP. For example, path
  computation MAY restrict the path taken by an LSP to only the links
  whose interface switching capability is PSC.

I wonder how to read these requirements. So, yes, region could be taken
into account doing choosing paths. Is that something that MUST be
supported by implementations and protocols? I.e., is the MAY talking
about how these things are used, or what's actually mandatory
for implementors?

There are other instances of this elsewhere in the document, including
the first issue I listed above. I was confused by this, so perhaps some
clarification is needed.

Section 5.8 says:

  It MUST be possible to utilize network resources efficiently.

I have no idea how to verify whether the requirement has been
met. In this particular case Section 5.8 continues to some
more useful requirements (stated at a SHOULD level). I wonder
if the latter requirements are actually the ones that you should
be listing instead of the motherhood-and-apple-pie requirements
such as the above one. But then, what's the right requirement
level?

There are other instances of this in the document.

[Ballot discuss]
Section 5.4 says:

  Creation, deletion, and modification of LSPs MAY be triggered by
  adjacent layers or through operational actions to meet traffic
  demand changes, topology changes, signaling requests from the upper
  layer, and network failures.

I am very surprised to learn that LSP modification per operational actions
is just a MAY.

Section 5.7 says:

  Path computation MAY take into account LSP region and layer
  boundaries when computing a path for an LSP. For example, path
  computation MAY restrict the path taken by an LSP to only the links
  whose interface switching capability is PSC.

I wonder how to read these requirements. So, yes, region could be taken
into account doing choosing paths. Is that something that MUST be
supported by implementations and protocols? I.e., is the MAY talking
about how these things are used, or what's actually mandatory
for implementors?

There are other instances of this elsewhere in the document, including
the first issue I listed above. I was confused by this, so perhaps some
clarification is needed.

[Ballot discuss]
Section 5.4 says:

  Creation, deletion, and modification of LSPs MAY be triggered by
  adjacent layers or through operational actions to meet traffic
  demand changes, topology changes, signaling requests from the upper
  layer, and network failures.

I am very surprised to learn that LSP modification per operational actions
is just a MAY.

Section 5.7 says:

  Path computation MAY take into account LSP region and layer
  boundaries when computing a path for an LSP. For example, path
  computation MAY restrict the path taken by an LSP to only the links
  whose interface switching capability is PSC.

I wonder how to read these requirements. So, yes, region could be taken
into account doing choosing paths. Is that something that MUST be
supported by implementations and protocols? I.e., is the MAY talking
about how these things are used, or what's actually mandatory
for implementors?

[Ballot discuss]
Section 5.4 says:

  Creation, deletion, and modification of LSPs MAY be triggered by
  adjacent layers or through operational actions to meet traffic
  demand changes, topology changes, signaling requests from the upper
  layer, and network failures.

I am very surprised to learn that LSP modification per operational actions
is just a MAY.

[Ballot comment]
There are a number of editorial/formatting issues in this spec. Sections start the first paragraph with an extra space, Section number indents are wrong in 5.4, terms used before expanded (LSP), etc.

[Ballot comment]
There are a number of editorial/formatting issues in this spec. Sections start the first paragraph with an extra space, Section number indents are wrong in 5.4, etc.

[Ballot comment]
While it is obvious from the Table of Contents, it would be helpful if the Introduction
noted that sections 3 and 4 provide background and the requirements are all captured
in section 5.

I am a little concerned about unstated requirements.  There are very few MUST statements
in section 5 (and some of them are MUST NOTs).  For example, section 5.7 has a number
of MAY statements but no clear requirements.  (Section 3.2.1 of mln-eval implies that
support for multi-region signaling was the requirement.)

I would encourage the authors to review section 5 to ensure that the important requirements
are clearly highlighted.

[Ballot discuss]
The background material is very extensive and well written. The requirements are pretty straightforward albeit short and to the point in Section 5. Should there be a section on MLN OAM requirements? Protection Switching requirements?

Proto-write-up for draft-ietf-ccamp-gmpls-mln-reqs-07 by Adrian Farrel:

Intended status : Informational

Recommend that this I-D is progressed in parallel with draft-ietf-ccamp-gmpls-mln-eval-05.txt requested for publication at the same time.


> (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?

Adrian Farrel is the document shepherd.
He has personally reviewed the I-D and believes it is ready for forwarding to the IESG for publication.

> (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?

Long list of authors/contributors.

This document has been reviewed by the CCAMP working group and discussed quite extensively at IETF meetings and on the mailing list.

In addition, the I-D received thorough review on liaison from Question
14 of Study Group 15 of the ITU-T.

These reviews have been sufficiently deep and broad.

> (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 concerns.

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

The document is sound.

An IPR disclosure can be found at https://datatracker.ietf.org/ipr/518/
and was filed against the -00 version of this I-D when it was still an individual submission.

This was brought to the attention of the working group, but no-one had any issues. Since this is an Informational Requirements I-D, it might be unlikely that there would be any implementation of the I-D to be impacted by the IPR claim.

> (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?

There were no problems with consensus for this document.

> (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 threats. No discontent.

> (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?

All checks made.

> (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].

References split.
No downrefs.

> (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 [RFC2434].  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?

This is an Informational I-D.
A null IANA section is present.

> (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?

No such sections.

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

Most of the initial efforts to utilize Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability. The complexity raised by the control of such data planes is similar to that seen in classical IP/MPLS networks.
By extending MPLS to support multiple switching technologies, GMPLS provides a comprehensive framework for the control of a multi- layered network of either a single switching technology or multiple switching technologies.

In GMPLS, a switching technology domain defines a region, and a network of multiple switching types is referred to in this document as a Multi-Region Network (MRN). When referring in general to a layered network, which may consist of either a single or multiple regions, this document uses the term, Multi-Layer Network (MLN).

This document defines a framework for GMPLS based multi-region/ multi-layer networks and lists a set of functional requirements.

>        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?

There was some unresolved debate about the term "virtual TE link" and whether it should be replaced with "potential TE link". However, since the former had been in use for a long time and was used in published RFCs, and since there was not great support for a change, we retained "virtual".

>        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 an Informational I-D with no protocol specifications.
Expert review of multi-layer network architecture was received from the ITU-T.