(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?
The target status is Protposed Standard. This document extends the
TRILL Protocol which is a Proposed Standard. The title page header
says "Standards Track".
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement
Write-Up. The approval announcement contains the following
sections:
Technical Summary:
TRILL provides optimum routing for layer 2 traffic. A centralized
gateway solution is typically used for layer 3 inter-subnet traffic
forwarding in a TRILL campus but has the following issues:
1. Sub-optimum forwarding paths for inter-subnet traffic.
2. A centralized gateway may need to support a very large number of
gateway interfaces in a data center, one per tenant per data
label used by that tenant, to provide interconnect functionality
for all the layer 2 virtual networks in a TRILL campus.
3. A traffic bottleneck at the gateway.
This document specifies an optional TRILL distributed gateway solution
that resolves these centralized gateway issues.
Working Group Summary:
There has been good support from the working group to advance this
work. There have been no changes in the concept or basic
architecture since it was adopted as a WG draft.
Document Quality:
This document is of high quality. It has received numerous reviews
including the RTG DIR QA review here:
http://www.ietf.org/mail-archive/web/trill/current/msg07133.html
Implementations are planned by IPinfusion and Huawei.
Personnel:
Document Shepherd: Donald Eastlake
Responsible Area Director: Alia Atlas
WG Chairs: Jon Hudson, Sue Hares
RTG-DIR QA person: Susan Hares
http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02783.html
(3) Briefly describe the review of this document that was performed by
the Document Shepherd.
I have carefully review the document previously and did a final check
resulting in the recommendations at
http://www.ietf.org/mail-archive/web/trill/current/msg07085.html. These
have been incorporated into revision -09.
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
No. As well as the other reviews, Alia Atlas did an early AD review
and her comments were resolved.
(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?
Final Routing Directorate review needs to be done.
(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?
No special concerns or issues.
(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.
Yes.
(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
Weiquo Hao IPR
https://mailarchive.ietf.org/arch/msg/trill/PvZ_oIJV4qFyCrNCVAf2ibLKgXg
Yizhou Li IPR:
https://mailarchive.ietf.org/arch/msg/trill/XKFEnGyrDNdR9WGLFFREzxMv-Wk
Frank Xialiang
https://mailarchive.ietf.org/arch/msg/trill/9R3AMezrAz1Bb-zf-AdQbKhm0vo
Muhammad Durrani (mdurrani@cisco.com)
https://mailarchive.ietf.org/arch/msg/trill/FCgebA1Kfe5X2ZhmZs2c5lVMLVc
P. Sivamurugan
11/14/2016 at 1:07am - I am not aware of any IPR
Andrew Qu
11/4/2015 at 1:27am - I am not aware of any IPR
No.
(9) 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 is broad support for this document.
(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?
No.
(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).
The nits checker incorrectly flags the reference to the ISO/IEC
IS-IS standard as a possible downref and incorrectly flags some ASCII
art that uses pound sign ("#") as possible code.
(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type
reviews.
No such review required.
(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?
There is a reference to draft-ietf-trill-rfc7180bis but it has been
approved for publication as a Proposed Standard RFC and is in the RFC
Editor's queue.
(15) Are there downward normative references references (see RFC
3967)?
There are no actual downward normative references. (The nits checker
warns about the reference to the ISO/IEC IS-IS standard as a possible
downward reference.)
(16) Will publication of this document change the status of any
existing RFCs.
This document does not change the status of any existing RFC.
(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).
The Shepherd has paid close attention to the IANA Considerations
section and that section incorporates earlier Shepherd comments. There
are appropriate code point reservations for all protocol extensions in
this document, the relevanr IANA registries are clearly identified.
This document does not creat any new IANA registries.
(18) List any new IANA registries that require Expert Review for
future allocations.
This document does not create any new IANA registries.
(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
No such automated checks are required.