(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 is targeted at Proposed Standard as indicated on the title
page. This document specifies protocol behavior of TRILL switches
to implement active-active services at the TRILL edge using a
pseudo-nickname to represent an edge group of RBridges.
(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:
Active-active access at the TRILL edge is the extension of flow
level multi-pathing and rapid fail-over service available in the
interior of a TRILL campus to end stations that are multiply
connected to a TRILL campus edge as discussed in RFC 7379. In this
document, a Virtual RBridge's pseudo-nickname represents the edge
RBridge group providing active-active access to such an end
Working Group Summary:
Early discussion in the TRILL WG favored a pseudo-node nickname
approach similar to that in this draft. Later analysis resulted in
the three alternatives described in the Introduction to
draft-ietf-trill-aa-multi-attach. Two of these, which can be
deployed simultaneously in a TRILL campus, are being advanced by
the WG, an evolved version of alternative 1 using a pseudo-nickname
in this draft and alternative 3 in draft-ietf-trill-aa-multi-
There was good WG support for this draft.
This document was developed by the WG over a two-year period. The
document is of good quality and is being implemented.
Document Shepherd: Donald Eastlake, 3rd
Responsible Area Director: Alia Atlas
(3) Briefly describe the review of this document that was performed by
the Document Shepherd.
The Shepherd has reviewed this document at various stages and
provided feedback. The most recent and formal Shepherd review is
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
(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?
(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.
(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.
(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
Two IPR disclosures have been filed against this draft. See
These IPR disclosures were not noted in the first WG Last Call on
this draft and a 2nd WG Last Call was specifically held due to that
oversight. There were no objections.
(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?
Many members of the WG have been involved in the development of
strategies to provide active-active support at the TRILL edge
[RFC7379]. This draft represents the original direction decided by
the original active-active design team coordinated by Tissa
Senevirathne. Consensus for this draft continues to be reasonably
(10) Has anyone threatened an appeal or otherwise indicated extreme
(11) Identify any ID nits the Document Shepherd has found in this
There are no actual nits. The nits checker complains about
non-RFC5735-compliant IPv4 addresses, but these are references to
level 4 sections in other documents.
(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
No formal review required.
(13) Have all references within this document been identified as
either normative or informative?
(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?
This document has normative references to draft-ietf-trill-cmt and
draft-ietf-trill-rfc7180bis both of which have passed WG Last Call.
(15) Are there downward normative references (see RFC 3967)?
No, although there is a reference to the ISO/IEC IS-IS standard
about which the nits checker warns.
(16) Will publication of this document change the status of any
(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
The IANA Considerations were carefully compared with the rest of
the text. It requests appropriate assignments from the "TRILL
APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1"
Registry. No other registries are used and no new registries
(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.
No IANA registries created.
(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 review required.