Version: 24 February 2012.
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?
Proposed standard
This RFC does not change the status of any existing RFC. It does,
however, as listed on the title page and in the abstract, updates two
RFCs: 7177 and 7178. These updates are as described in Sections 5 and
11.3.
(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
The TRILL (Transparent Interconnection of Lots of Links) protocol
supports both point-to-point and multi-access links and is designed
so that a variety of link protocols can be used between TRILL switch
ports. This document specifies transmission of encapsulated TRILL
data and TRILL IS-IS over IP (v4 or v6) transport. so as to use an IP
network as a TRILL link in a unified TRILL campus. This document
updates RFC 7177 and updates RFC 7178.
Working Group Summary
Consensus is strong with one outlier: Joe Touch
regarding use of IPSEC + TCP/UDP
See mail thread:
https://www.ietf.org/mail-archive/web/trill/current/msg08185.html
Why did we choose this approach:
In our working group investigation of this draft,
the WG was visited by vendors implementing TRILL
(most noteable at IETF 91). The vendors requested
the IPSEC + Transport approach.
While there are other approaches, no
vendor of TRILL equipment has requested the approach.
Document Quality
Are there existing implementations of the protocol?
See comments above, hardware vendors looking for line rate speed
came to IETF 91 to give feedback to TRILL.
These vendors were in addition to the Huawei and IPInfusion implementations.
Personnel
Document Shepherd: Susan Hares
AD: Alia Atlas
RTG-QA review: Ines Robles
https://datatracker.ietf.org/doc/review-ietf-trill-over-ip-08-rtgdir-early-robles-2016-12-27/
TSV-Area review: Magnus WEstlund
https://datatracker.ietf.org/doc/review-ietf-trill-over-ip-10-tsvart-early-westerlund-2017-06-15/
[note: Shepherd believes according to Email that Magnus has agreed to all changes]
(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.
1) Reviewed Draft
2) Discussed the draft concerns with Joe Touch (outlier) via phone
Joe's issuses: Name of draft, and use of GRE with hardware offload, quality of draft.
3) Reviewed resolution to TSV Review and INT review
On name of draft - requested - propose change.
On GRE + Hardware offload - vendors at IETF 91 specifically asked for something else.
Time has gone on, but the WG chooses to go with Trill vendors stated goal.
On quality of writing, authors have addressed technical issues from RTG-QA review,
and TSV-QA review. More is possible, but we are reaching diminishing returns.
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
No.
(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 additional forms. IANA review should occur during IETF LC.
(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?
Discussion above covers it.
(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.
Donald Eastlake
https://mailarchive.ietf.org/arch/msg/trill/1zjCvNpD_PejMJOjl8Gj9ljNUDE
Mingui Zhang
https://mailarchive.ietf.org/arch/msg/trill/1eoTyUzdSrBCIKkbusxjenlYFH4
Dacheng Zhang
https://mailarchive.ietf.org/arch/msg/trill/cmeBtvnwvRjcqiU-8fE2drVVCXY
Margaret Cullen
https://www.ietf.org/mail-archive/web/trill/current/msg07773.html
(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
No IPR disclosures
(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?
Major of WG has worked on the issues since IETF 89.
The "please ship it" is the majority view.
I've given you the minority view in discussion above.
(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.)
Joe Touch (who is the outlier vote) will not block or appeal.
Joe has not actively particpate in IETF discussions since IETF 89.
He has contributed on email list regarding this draft.
(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
Nits complains about ISO 10589 - (IDNITS folks - please fix)
Normative drafts that is not RFC:
draft-ietf-tsvwg-le-phb - WG draft only, expected to go RFC
Informative drafts that are not RFC, and expected from other WGs:
draft-ietf-trill-ecn-support -- past WG , at IESG resolution (revised ID needed)
draft-ietf-intarea-tunnels - expected to head toward RFC
TRILL WG:
draft-ietf-trill-link-gk-profiles- group keying protocol TRILL profile
The last draft deserves a comment. The security ADs during the
life of this draft have asked about secure key distribution for multicast groups.
The draft-ietf-trill-group-keying was the general purpose protocol the
WG designed to handle this issue.
The draft-ietf-trill-link-gk-profiles is the adaption of the general purpose
protocol to TRILL.
As TRILL is closing, the draft-ietf-group-keying draft we hope will be
taken on by the security dispatch group. The draft needs review by
security expert. If the security dispatch group picks it up as important,
the rtgwg can handle the draft-ietf-trill-link-gk-profiles.
If the security Area feels it is unimportant, then this information reference can be
deleted by the RFC editor.
(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
(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?
One normative reference is not RFC:
draft-ietf-tsvwg-le-phb - is a WG draft, and expected to progress.
recommended to deal with congestion.
(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.
See #14 -
(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.
This RFC does not change the status of any existing RFC. It does,
however, as listed on the title page and in the abstract, updates two
RFCs: 7177 and 7178. These updates are as described in Sections 5 and
11.3.
(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).
IANA Considerations look good. This document allocates an IPv4
multicast address, an IPv6 multicast address, and two ports. It also
makes changes to the "RBridge Channel Protocols" registry as descirbed
in item 18 below.
(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.
This draft performs surgery on the "RBridge Channel Protocols"
registry on the TRILL Parameters IANA web page. It is renamed to be
the "RBridge Channel Protocols and Link Technology Specific Flags"
registry and a range of the code points in that registry are changed
into a link-technology-dependent set of flag bits. A sub-registry is
then added for the IP technology link type where the flags indicate
encapsulation support and 3 of these flag bit initially
allocated. Future allocations in this new sub-registry are by Expert
Review. Appropriate expertise for this sub-registry is expertise in
TRILL and IP.
(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.