> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)? Why is
> this the proper type of RFC? Is this type of RFC indicated in the
> title page header?
This document is requested for publication as an Informational RFC.
The document describes the applicability of existing protocols and
outlines an architecture. It also identifies some gaps in existing
protocols. It does not specify any protocols and does not describe
how to implement anything.
The title page shows "Informational"
> (2) 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
Services such as content distribution, distributed databases, or
inter-data center connectivity place a set of new requirements on the
operation of networks. They need on-demand and application-specific
reservation of network connectivity, reliability, and resources (such
as bandwidth) in a variety of network applications (such as point-to-
point connectivity, network virtualization, or mobile back-haul) and
in a range of network technologies from packet (IP/MPLS) down to
optical. An environment that operates to meet this type of
requirement is said to have Application-Based Network Operations
(ABNO).
ABNO brings together many existing technologies for gathering
information about the resources available in a network, for
consideration of topologies and how those topologies map to
underlying network resources, for requesting path computation, and
for provisioning or reserving network resources. Thus, ABNO may be
seen as the use of a toolbox of existing components enhanced with a
few new elements. The key component within an ABNO is the Path
Computation Element (PCE), which can be used for computing paths and
is further extended to provide policy enforcement capabilities for
ABNO.
This document describes an architecture and framework for ABNO
showing how these components fit together. It provides a cookbook of
existing technologies to satisfy the architecture and meet the needs
of the applications.
Working Group Summary
This document is not the product of any IETF working group. There is
currently no working group chartered to work on this topic.
However, the document has been widely circulated for review with
focus in the PCE, ALTO, and OPSAWG. Notification of the document with
a request for review was also sent to the I2RS and RTGWG working
groups. The SDNRG of the IRTF has had this work presented at several
IETF meetings.
Document Quality
There are currently believed to be two implementations of network
management packages in operators' research labs that are based on the
architectural model described here. A further implementation is
rumored to be planned by a third network operator.
Although the operators have not been publically forthcoming about
their implementations, some information can be found at:
http://www.vlopezalvarez.com/Profesional/Publications/Conferences/2014_OFC_1.pdfhttp://www.infinera.com/pdfs/misc/Infinera-Telefonica_SDN_Demo.pdfhttps://www.fi-athens.eu/sites/default/files/presentations/ABNO.pdfhttp://www.cttc.es/publication/experimental-assessment-of-abno-based-network-orchestration-of-end-to-end-multi-layer-opsocs-provisioning-across-sdnopenflow-and-gmplspce-control-domains/
Personnel
Quintin Zhao <quintin.zhao@huawei.com> is the Document Shepherd.
Alia Atlas <akatlas@gmail.com> is the Responsible Area Director.
> (3) Briefly describe the review of this document that was performed
> by the Document Shepherd. If this version of the document is not
> ready for publication, please explain why the document is being
> forwarded to the IESG.
I have read the latest version of this document and I am a contributing
author. I believe the document is comprehensive, has been widely
reviewed, and is ready for publication.
> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?
I have no such concerns. I would have liked to see more feedback from
the operational community, but the existing implementations based on
this architecture provide good evidence of operator review.
> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization? If so, describe the review that
> took place.
No such review needed.
> (6) Describe any specific concerns or issues that the Document
> Shepherd has 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 interested
> community has discussed those issues and has indicated that it still
> wishes to advance the document, detail those concerns here.
No concerns.
> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of
> BCP 78 and BCP 79 have already been filed. If not, explain why.
All authors and contributors made a confirmation via email copying each
other and the responsible AD.
One contributor initially stated that he believed there was IPR that
needed to be disclosed, but after consideration he withdrew this
statement and clarified that he knew of no relevant IPR.
> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any discussion and conclusion regarding the IPR
> disclosures.
No IPR disclosures have been made.
> (9) How solid is the consensus of the interested community behind this
> document? Does it represent the strong concurrence of a few
> individuals, with others being silent, or does the interested
> community as a whole understand and agree with it?
It is hard to measure the consensus for this document without a mailing
list or community specifically dedicated to the work. However, the high
level of support across operator and vendor communities has been quite
surprising to the authors, and there are already a number of research
papers and implementations based on this architecture.
There have been quite a few useful reviews making constructive comments
that have been absorbed into the document, and no negative comments have
been seen.
> (10) 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 publicly available.)
No threats or discontent.
> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See http://www.ietf.org/tools/idnits/ and the Internet-
> Drafts Checklist). Boilerplate checks are not enough; this check needs
> to be thorough.
The document passes through idnits cleanly (with two level-four section
numbers being identified as potential IPv4 addresses).
The document has been checked by the author against the Internet-Drafts
Checklist.
> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.
No formal criteria apply to this document.
> (13) Have all references within this document been identified as
> either normative or informative?
Yes.
> (14) 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 plan for their completion?
No. All references in this document are Informative.
> (15) Are there downward normative references references (see RFC
> 3967)? If so, list these downward references to support the Area
> Director in the Last Call procedure.
No. All references in this document are Informative.
> (16) Will publication of this document change the status of any
> existing RFCs? Are those RFCs listed on the title page header,
> listed in the abstract, and discussed in the introduction? If the
> RFCs are not listed in the Abstract and Introduction, explain why,
> and point to the part of the document where the relationship of this
> document to the other RFCs is discussed. If this information is not
> in the document, explain why the interested community considers it
> unnecessary.
No.
> (17) Describe the Document Shepherd's review of the IANA
> considerations section, especially with regard to its consistency
> with the body of the document. Confirm that all protocol extensions
> that the document makes are associated with the appropriate
> reservations in IANA registries. Confirm that any referenced IANA
> registries have been clearly identified. Confirm that newly created
> IANA registries include a detailed specification of the initial
> contents for the registry, that allocations procedures for future
> registrations are defined, and a reasonable name for the new registry
> has been suggested (see RFC 5226).
This document contains a valid nul IANA section. This is appropriate
for the type of document and considering its contents.
> (18) List any new IANA registries that require Expert Review for
> future allocations. Provide any public guidance that the IESG would
> find useful in selecting the IANA Experts for these new registries.
N/A
> (19) Describe reviews and automated checks performed by to validate
> sections of the document written in a formal language, such as XML
> code, BNF rules, MIB definitions, etc.
No such sections.