Transparent Interconnection of Lots of Links (TRILL) Distributed Layer 3 Gateway
draft-ietf-trill-irb-14

[Ballot comment]
Here is Scott Bradners' OPS directorate review:
I performed an OPS-DIR review of draft-ietf-trill-irb-13.txt.

Summary: the technical specification seems ready to be published but
management considerations are not mentioned.

I found the document to be a confusing read, likely because it is not easy to
explain the forwarding behavior but I expect that the document is clear
enough to implement from.

What I did not find was any discussion of management - maybe that is
covered in the MIB or OAM documents listed in the TRILL charter.
If so, it might be good to reference the right documents.  If not, then it
would be good to have some suggestions about what to instrument for management.

Balloting no objection based on the interaction with Donald Eastlake, assuming some text will be provided:
The configuration information is visible in the link state database. A
reference to the appropriate OAM documents could be added.

Regards, Benoit

[Ballot discuss]
* Section 6 has a few errors that need to get fixed before this document goes forward. e.g. It is not clear what a "192.0.2.0/32" subnet means especially since the only host shown to be on the subnet 192.0.2.2 cannot obviously fall inside the subnet range. The /32 needs to be replaced with something shorter depending on what the authors/WG intended (say a /24).
* RB2 seems to be advertising ES2s IPv4 address 198.51.100.2/32 instead of the prefix of the subnet while RB1 seems to be advertising the the IPv4 prefix of the ES1 subnet. One of these is wrong. Not sure which one is intended.
* What is the rationale for using a /112 IPv6 prefix for numbering an IPv6 link with hosts? Things like SLAAC (RFC4862) will not work in such links. Is there a reason the authors want to use a longer than /64? Please read RFC7421 for advantages of using a /64 instead and to find out what things break if you do not use a /64.

[Ballot comment]
Section 5: What does "Layer 2 routing" mean in this context?
Sections 7.3 & 7.4: What is the point of including these sub-TLVs if no prefix is being advertised? (The Total Length=0 case specified in the document)

[Ballot comment]
Two minor comments:

1) There are only few SHOULDs and MUSTs in this whole document
  and where they are used it is often not very clear what the action
  is that should follow and how it should be implemented
  (e.g. "The network operator MUST ensure the consistency of the
  tenant ID on each edge RBridge for each routing domain.").
  And maybe there are actually more case where normative
  language should be used?
  Please double-check the use of normative langauge in this document!

2) A similar question on the following part:
  „If a tenant is deleted on an edge RBridge RB1, RB1 SHOULD re-
  advertise the local tenant Data Label, tenant gateway MAC, and
  related IP prefixes information of the rest tenants to other edge
  RBridges. […] Therefore the transient routes consistency won't
  cause issues other than wasting some network bandwidth.“
  Wasting network resources actually can be an issue.
  So why is this not an MUST?

[Ballot comment]
Two minor comments:

1) There are only few SHOULDs and MUSTs in this whole document
  and where they are used it is often not very clear what the action is
  that should follow and how it should be implemented
  (e.g. "The network operator MUST ensure the consistency of the
  tenant ID on each edge RBridge for each routing domain.").
  And maybe there are actually more case where normative
  language should be used?
  Please double-check the use of normative langauge in this document!

2) A similar question on the following part:
  „If a tenant is deleted on an edge RBridge RB1, RB1 SHOULD re-
  advertise the local tenant Data Label, tenant gateway MAC, and
  related IP prefixes information of the rest tenants to other edge
  RBridges. […] Therefore the transient routes consistency won't
  cause issues other than wasting some network bandwidth.“
  Wasting network resources actually can be an issue.
  So why is this not an MUST?

[Ballot comment]
A few minor comments

1) There are only few SHOULDs and MUSTs in this whole document
  and where they are used it is often not very clear what the action is
  that should follow and how it should be implemented
  (e.g. "The network operator MUST ensure the consistency of the
  tenant ID on each edge RBridge for each routing domain.").
  And maybe there are actually more case where normative language should be used?
  Please double-check the use of normative langauge in this document!

2) A similar question on the following part:
  „If a tenant is deleted on an edge RBridge RB1, RB1 SHOULD re-
  advertise the local tenant Data Label, tenant gateway MAC, and
  related IP prefixes information of the rest tenants to other edge
  RBridges. […] Therefore the transient routes consistency won't
  cause issues other than wasting some network bandwidth.“
  Wasting network resources actually can be an issue. So why is this not an MUST?

[Ballot comment]
In reading the draft and security considerations, I had the same concern as Stephen's second point.  Are there any security issues if the session is not encrypted?  I see the concern for sensitive data and that is good, but are any exploits possible if the session is not encrypted (like on the tenantID as Stephen asked).

[Ballot comment]

- section 5: The tenant ID is sometimes described as "globally
unique" and sometimes (in 5.2) as "throughout the campus." The
latter seems likely correct to me. (As an aside, is this document
the first to introduce that concept to TRILL?)

- section 8: If IS-IS security is not actually used, (is that the
current deployment reality btw?) and if I can guess a tenant ID then
what new mischief can happen? If there is some, then perhaps you
ought recommend that tenant ID's be randomly selected within the
campus? (I see you use "1" in the example, which is pretty easy to
guess:-) I think one could argue that that (and maybe more) ought be
covered in section 8, if the current deployment reality is that no
crypto is actually used to protect most IS-IS traffic. Is it?

[Ballot comment]
Just a couple of nits:

- Please expand TRILL in the abstract.

- Figure 1: I see what ToR means, but what about AGG and COR? (I can guess, but a definition would be helpful.)

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-trill-irb-13.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which much be completed.

First, in the TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1 subregistry of the Transparent Interconnection of Lots of Links (TRILL) Parameters registry located at:

http://www.iana.org/assignments/trill-parameters/

three values in the range less than 255 are to be registered as follows:

Type: [ TBD-at-registration ]
Name: TENANT-GWMAC-LABEL
Reference: [ RFC-to-be ]

Type: [ TBD-at-registration ]
Name: IPV4-PREFIX
Reference: [ RFC-to-be ]

Type: [ TBD-at-registration ]
Name: IPV6-PREFIX
Reference: [ RFC-to-be ]

Second, in the NickFlags Bits subregistry also in the Transparent Interconnection of Lots of Links (TRILL) Parameters registry located at:

http://www.iana.org/assignments/trill-parameters/

a new bit is to be registered as follows:

Bit: 1
Mnemonic: SE
Description: Inter-Subnet Egress
Reference: [ RFC-to-be ]

IANA understands that, upon approval of this document, these are the only actions that need to be completed by IANA.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: d3e3e3@gmail.com, trill-chairs@ietf.org, draft-ietf-trill-irb@ietf.org, trill@ietf.org, akatlas@gmail.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (TRILL Distributed Layer 3 Gateway) to Proposed Standard


The IESG has received a request from the Transparent Interconnection of
Lots of Links WG (trill) to consider the following document:
- 'TRILL Distributed Layer 3 Gateway'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-06-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The base TRILL protocol provides optimal pair-wise data frame
  forwarding for layer 2 intra-subnet traffic but not for layer 3
  inter-subnet traffic. A centralized gateway solution is typically
  used for layer 3 inter-subnet traffic forwarding but has the
  following issues:




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-trill-irb/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-trill-irb/ballot/


No IPR declarations have been submitted directly on this I-D.

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

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

(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
(no IPR disclosure listed)  - resent query on 2/8/2016

Andrew  Qu
(no IPR disclosure)  - resent query on 2/8/2016
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.

(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

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

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.

(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

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd.

I have carfully 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.

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

(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
  and implementations are planned by at least IPinfusion and Huawei.

Personnel:

  Document Shepherd:  Donald Eastlake
  Responsible Area Director:  Alia Atlas

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd.

I have carfully 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?

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.

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 incrrectly flags some ASCII
art that usese 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.

(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
  and implementations are planned by at least IPinfusion and Huawei.

Personnel:

  Document Shepherd:  Donald Eastlake
  Responsible Area Director:  Alia Atlas

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd.

I have carfully 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.

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

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.

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 incrrectly flags some ASCII
art that usese pound sign ("#") as possible code. There are also two
glitches in -08: "RC7172" should be "RFC7172" and "fpr" should be
"for".

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

(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 some very minor technical changes in the
  draft while it was a WG draft but no changes in the concept or
  basic architecture.

Document Quality:

  This document is of high quality. It has received numerous reviews
  and implementations are planned by at least IPinfusion and Huawei.

Personnel:

  Document Shepherd:  Donald Eastlake
  Responsible Area Director:  Alia Atlas

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd.

I have carfully 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.

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

Routing Directorate review tbd

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

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

tbd The nits checker incorrectly flags the reference to the ISO/IEC
IS-IS standard as a possible downref.

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