Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms
draft-ietf-trill-directory-assist-mechanisms-12

[Ballot comment]
Thank you for addressing my DISCUSS.

This document makes me wonder if the cure is worse than the disease... This looks rather complicated with all options.

[Ballot comment]


- 2.6: I wondered why this was useful. Is it for cases where
the secondary push service is differently connected or is it
in case the primary goes down? Might be good to say.

- section 6: what security mechanism differences are there
between the push and pull cases? Why aren't those called out
here?  Forcing the reader to delve into the various other
security mechanism RFCs and figure this out themselves seems
less good.

- section 6: apologies if I asked this before (in which case I
forget the answer;-) but how fictional/real is the crypto
stuff with TRILL in terms of the likelihood of it being
actually used? I ask again, as if the crypto stuff is mostly
fictional, then I think you ought note that here, given the
attack surface that the directory function creates.

[Ballot comment]
It's not clear to me why a new protocol for the pull case is needed (instead of using an existing one). However, I also don't have enough background knowledge on trill to make a judgement here.

[Ballot discuss]
In Section 3.1 there is a Version field. What are the condition(s) for bumping this version number? What backward compatibility guaranties are expected (if any)? How would version negotiation be done?

[Ballot comment]
I would like to see some more information related to the overall operation of the network, including guidance on how/when to use different mechanisms and their location.  Specifically, I think this document should include more information in these cases:

[1] Server Learning and Advertisement of information in ESADI [RFC7357] using the Reachable MAC Addresses TLV [RFC6165].

I don't think it is explicit in the document, but I'm assuming that the Servers (for both Push and Pull) learn using the mechanisms in Section 4.8.1. (Learning End-Station Addresses) of RFC6325.  One of those mechanisms is to use ESADI...Section 2.5 (Additional Push Details) says:

  TRILL switches, whether or not they are a Push Directory server, MAY
  continue to advertise any locally learned MAC attachment information
  in ESADI [RFC7357] using the Reachable MAC Addresses TLV [RFC6165].
  However, if a Data Label is being served by complete Push Directory
  servers, advertising such locally learned MAC attachment generally
  SHOULD NOT be done as it would not add anything and would just waste
  bandwidth and ESADI link state space. An exception might be when a
  TRILL switch learns local MAC connectivity and that information
  appears to be missing from the directory mapping.

It seems to me that a switch advertising information in ESADI using the Reachable MAC Addresses TLV is independent of whether Push or Pull is being used on the network (or for a specific Data Label), so I think my questions/comments below apply to both.

I understand why using the information in the Reachable MAC Addresses TLV may be redundant, but as the text points out, there are cases where it may be a good thing.  I would like to see guidelines or suggestions on the use of "traditional" ESADI learning (RFC7357) in Section 4. (Directory Use Strategies and Push-Pull Hybrids).  This section already talks about what a TRILL switch may do if it doesn't have complete information, but it doesn't talk about what a Directory Server could do.

Related to the above, if ESADI [RFC7357] using the Reachable MAC Addresses TLV [RFC6165] does't really add anything to the Push Directory service, then it seems to me that they would be equivalent (the outcome is the same) -- when should one be used over the other?  Are there cases where the centralized service may not scale and is better to adopt a distributed strategy?  It seems to me than the options in Section 4. (Directory Use Strategies and Push-Pull Hybrids) may not be just between Pull and Push...


[2] Location and Priority of Push Directory Servers

Section 2.2 (Push Directory Servers) talks about PushDirPriority, but there are no guidelines as to how it should be set by an operator.  I suspect that a higher priority may want to be assigned to Directory Servers with a higher density of connected high-use stations...or maybe not, which is why I would like you to provide some guidance.


[3] Location and Number of Requests for Pull Directory Servers

Section 3.(Pull Model Directory Assistance Mechanisms) reads:

  If multiple data reachable TRILL switches indicate in the link state
  database that they are Pull Directory Servers for a particular Data
  Label, pull requests can be sent to any one or more of them but it is
  RECOMMENDED that pull requests be preferentially sent to the server
  or servers that are lowest cost from the requesting TRILL switch.

Are there guidelines related to the location (and number) of these servers?

When would a switch not send a request to the server(s) with the lowest cost?  IOW, why "RECOMMENDED" and not "MUST"?

How many servers should the request be sent to?  For the Push case, a default of 2 copies is specified -- should 2 requests be enough?  Are there cases where more are needed?

[Ballot comment]
Since this document implies the creation of centralized databases of addressing information, I think it would help to call out in Section 6 the need to secure the directory contents themselves, not just against abuses of the push or pull services but in general against unauthorized access.

Also, I recall in prior evaluations of TRILL documents some discussion about how TRILL deals with ephemeral MAC addresses and my recollection is that they are likely prohibited by policy on TRILL networks. But if there is some interaction between ephemeral MAC addresses and the services described in this document that would be good for implementors to be aware of, those are probably worth mentioning.

[Ballot comment]
In this text,

      It might learn that information from
      the directory or could query the directory if it does not know.

is "learning information from the directory" different from "querying the directory"? My apologies for not knowing TRILL well.

I found this text,

    A Push Directory also advertises whether or not it
    believes it has pushed complete mapping information for a Data Label.

to be odd ("directories believe things?"), and I'm wondering what that belief would be based on. If a Push Directory has pushed all the information it's currently storing, is that what's being described here? Or does this mean something else?

In section 2.3.1, there are several states that refer to "enough time for propagation" - for example,

  Active Completing :  Same behavior as the Active state except
      that the server responds differently to events. The purpose of
      this state is to be sure there has been enough time for directory
      information to propagate to subscribing edge TRILL switches before
      the Directory Server advertises that the information is complete.

Is it possible to provide a pointer or reference that describes how "enough time" is calculated? I'm not sure whether this is referring to PushDirTimer in Section 2.7 or something else.

It's a nit, but I think this text,

      TRILL switches, whether or not they are a Push Directory server,

should be something like

      TRILL switches, whether or not they are Push Directory servers,

- there's a numbering mismatch.

I think this text,

  Thus, there is commonly a
  small window during which the an RBridge using directory information
  might either (1) drop or unnecessarily flood a frame as having an
  unknown unicast destination or (2) encapsulate a frame to an edge
  RBridge where the end station is not longer connected when the frame
  arrives at that edge RBridge.

is garbled (somewhere around "during which the an RBridge").

In this text,

  Support of TRILL ES-IS is generally optional for both the TRILL
  switches and the end stations on a link but may be required to
  support certain features.

can you give any guidance to the reader on how to know whether TRILL ES-IS support is required for a feature?

template for shepherd write (version: 1/9/2017)
Date of review: 2/8/2016, review in IETF LC (1/8/2017)
  Last shepherd update:  1/13/2017

1) type of RFC: Proposed standard (indicated on title page)
2) Shepherd: Susan Hares
3) WG chairs: Jon Hudson and Susan Hares

Technical Summary

  This document describes mechanisms for providing directory service to
  TRILL (Transparent Interconnection of Lots of Links) edge switches.
  The directory information provided can be used in reducing multi-
  destination traffic, particularly ARP/ND and unknown unicast
  flooding. It can also be used to detect traffic with forged source
  addresses.  Directory Service can utilize either a push or a pull mechanism.


Working Group Summary

This document is the result of 3 years of intensive discussion.
The WG consensus was complete even if the WG discussion at the
end of the three years was "Time to send this to IESG".

Document Quality
The Shepherd's review at 2/8/2016
https://mailarchive.ietf.org/arch/msg/trill/HZ5p1GTo_2vJT6xOPPDyVB15P3Q
Authors response:
https://mailarchive.ietf.org/arch/msg/trill/ezH1lwbqOwTBuC4h_WtcZ_QNaxw
Shepherd's review of changes and acceptance of changes (minus 2 editorial nits)
https://mailarchive.ietf.org/arch/msg/trill/oQjR3jwAKkayHvPRdKznCmOf8u4
Final resolution by Authors:
https://mailarchive.ietf.org/arch/msg/trill/FkSuXx4ugHIzYsuVIhE3xlOizZM

Shepherds post IETF LC review:
https://mailarchive.ietf.org/arch/msg/trill/SUMuYIuHz0bg1bSxXEZz9Vsnqjc
- Based on draft-ietf-trill-directory-assist-mechanism-10.txt
+ Suresh Krishnan's comments on SEND in
https://datatracker.ietf.org/doc/draft-ietf-trill-arp-optimization/ballot/
This Shepherd review looked for SEND related information and anything unspecified. 

Routing QA reviewer (follow email thread for review)
http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02676.html

AD review:
https://www.ietf.org/mail-archive/web/trill/current/msg07605.html

Personnel
  Document Shepherd:  Susan Hares (WG co-chair)
  Responsible Area Director: (Alia Atlas)
  WG chairs: Susan Hares and Jon Hudson
  Routing QA Reviewer: Matthew Bocci  (July 2015)

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

a) nits run
b) discussion with authors (see detail in Document quality)
c) Assured that Routing QA review was responded to

(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 - no additional QA reviews outside of routing directorate.
Normal final security-directorate, routing-directorate, GEN-ART, OPS-DIR reviews should be made.

(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 WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No issues to be concerned about. 
Directory assist is critical to standardize to advance TRILL.

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

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

3 IPR disclosures have been filed. The WG was informed regarding the IPR at WG LC.
https://datatracker.ietf.org/ipr/search/?submit=draft
&id=draft-ietf-trill-directory-assist-mechanisms

for LC comments.
https://mailarchive.ietf.org/arch/msg/trill/K1QekixHBxmHjEYzt5IRXaih_0A

Authors knew of no additional IPR
(see mail thread above)
Radia Perlman
https://mailarchive.ietf.org/arch/msg/trill/PJO4Qcc3ciJIjrArdPMIJqruEOI
Linda Dunbar
https://mailarchive.ietf.org/arch/msg/trill/dXH1ZSuxWyrA4T5sWYn5eo9Oogw
Donald Eastlake III
https://mailarchive.ietf.org/arch/msg/trill/Df_BhjKD5q43EQi9CGAcJTgTx6o
Yizhou Li
https://mailarchive.ietf.org/arch/msg/trill/TthWYuP8_KlqiW8DBi-yVEr1C3Y

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

Solid discussion after 3 years of work.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

No threats or conflict over 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.

No nits


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

None needed

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

[rfc7180bis]  - is the only normative reference not at RFC.
It is approved for publication and at the RFC Editor

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

[ARP optimization] -  is in WG, WG LC (2/8 to 2/22/2016)
[[ChannelTunnel]- has past WG LC (5 months, Awaiting QA Review).

(16) Will publication of this document change the status of any
existing RFCs? 
No change to existing RFCs.

(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 has previewed the 8 actions needed for this draft, and
indicated they have approved it.

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

None of the 8 actions this draft suggests require an expert review.

(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 XML code, no BNF rules, no MIB definitions in this draft.

template for shepherd write (version: 1/9/2017)
Date of review: 2/8/2016, review in IETF LC (1/8/2017)

1) type of RFC: Proposed standard (indicated on title page)
2) Shepherd: Susan Hares
3) WG chairs: Jon Hudson and Susan Hares

Technical Summary

  This document describes mechanisms for providing directory service to
  TRILL (Transparent Interconnection of Lots of Links) edge switches.
  The directory information provided can be used in reducing multi-
  destination traffic, particularly ARP/ND and unknown unicast
  flooding. It can also be used to detect traffic with forged source
  addresses.  Directory Service can utilize either a push or a pull mechanism.


Working Group Summary

This document is the result of 3 years of intensive discussion.
The WG consensus was complete even if the WG discussion at the
end of the three years was "Time to send this to IESG".

Document Quality
The Shepherd's review at 2/8/2016
https://mailarchive.ietf.org/arch/msg/trill/HZ5p1GTo_2vJT6xOPPDyVB15P3Q
Authors response:
https://mailarchive.ietf.org/arch/msg/trill/ezH1lwbqOwTBuC4h_WtcZ_QNaxw
Shepherd's review of changes and acceptance of changes (minus 2 editorial nits)
https://mailarchive.ietf.org/arch/msg/trill/oQjR3jwAKkayHvPRdKznCmOf8u4
Final resolution by Authors:
https://mailarchive.ietf.org/arch/msg/trill/FkSuXx4ugHIzYsuVIhE3xlOizZM

Shepherds post IETF LC review:
https://mailarchive.ietf.org/arch/msg/trill/SUMuYIuHz0bg1bSxXEZz9Vsnqjc
- Based on draft-ietf-trill-directory-assist-mechanism-10.txt
+ Suresh Krishnan's comments on SEND in
https://datatracker.ietf.org/doc/draft-ietf-trill-arp-optimization/ballot/
This review look for SEND and anything unspecified. 

Routing QA reviewer (follow email thread for review)
http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02676.html

AD review:
https://www.ietf.org/mail-archive/web/trill/current/msg07605.html

Personnel
  Document Shepherd:  Susan Hares (WG co-chair)
  Responsible Area Director: (Alia Atlas)
  WG chairs: Susan Hares and Jon Hudson
  Routing QA Reviewer: Matthew Bocci  (July 2015)

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

a) nits run
b) discussion with authors (see detail in Document quality)
c) Assured that Routing QA review was responded to

(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 - no additional QA reviews outside of routing directorate.
Normal final security-directorate, routing-directorate, GEN-ART, OPS-DIR reviews should be made.

(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 WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No issues to be concerned about. 
Directory assist is critical to standardize to advance TRILL.

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

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

3 IPR disclosures have been filed. The WG was informed regarding the IPR at WG LC.
https://datatracker.ietf.org/ipr/search/?submit=draft
&id=draft-ietf-trill-directory-assist-mechanisms

for LC comments.
https://mailarchive.ietf.org/arch/msg/trill/K1QekixHBxmHjEYzt5IRXaih_0A

Authors knew of no additional IPR
(see mail thread above)
Radia Perlman
https://mailarchive.ietf.org/arch/msg/trill/PJO4Qcc3ciJIjrArdPMIJqruEOI
Linda Dunbar
https://mailarchive.ietf.org/arch/msg/trill/dXH1ZSuxWyrA4T5sWYn5eo9Oogw
Donald Eastlake III
https://mailarchive.ietf.org/arch/msg/trill/Df_BhjKD5q43EQi9CGAcJTgTx6o
Yizhou Li
https://mailarchive.ietf.org/arch/msg/trill/TthWYuP8_KlqiW8DBi-yVEr1C3Y

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

Solid discussion after 3 years of work.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

No threats or conflict over 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.

No nits


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

None needed

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

[rfc7180bis]  - is the only normative reference not at RFC.
It is approved for publication and at the RFC Editor

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

[ARP optimization] -  is in WG, WG LC (2/8 to 2/22/2016)
[[ChannelTunnel]- has past WG LC (5 months, Awaiting QA Review).

(16) Will publication of this document change the status of any
existing RFCs? 
No change to existing RFCs.

(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 has previewed the 8 actions needed for this draft, and
indicated they have approved it.

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

None of the 8 actions this draft suggests require an expert review.

(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 XML code, no BNF rules, no MIB definitions in this draft.

template for shepherd write (version: 1/9/2017)
Date of review: 2/8/2016, review in IETF LC (1/8/2017)

1) type of RFC: Proposed standard (indicated on title page)
2) Shepherd: Susan Hares
3) WG chairs: Jon Hudson and Susan Hares

Technical Summary

  This document describes mechanisms for providing directory service to
  TRILL (Transparent Interconnection of Lots of Links) edge switches.
  The directory information provided can be used in reducing multi-
  destination traffic, particularly ARP/ND and unknown unicast
  flooding. It can also be used to detect traffic with forged source
  addresses.  Directory Service can utilize either a push or a pull mechanism.


Working Group Summary

This document is the result of 3 years of intensive discussion.
The WG consensus was complete even if the WG discussion at the
end of the three years was "Time to send this to IESG".

Document Quality
The Shepherd's review at 2/8/2016
https://mailarchive.ietf.org/arch/msg/trill/HZ5p1GTo_2vJT6xOPPDyVB15P3Q
Authors response:
https://mailarchive.ietf.org/arch/msg/trill/ezH1lwbqOwTBuC4h_WtcZ_QNaxw
Shepherd's review of changes and acceptance of changes (minus 2 editorial nits)
https://mailarchive.ietf.org/arch/msg/trill/oQjR3jwAKkayHvPRdKznCmOf8u4
Final resolution by Authors:
https://mailarchive.ietf.org/arch/msg/trill/FkSuXx4ugHIzYsuVIhE3xlOizZM

Shepherds post IETF LC review:
https://mailarchive.ietf.org/arch/msg/trill/SUMuYIuHz0bg1bSxXEZz9Vsnqjc
- Based on draft-ietf-trill-directory-assist-mechanism-10.txt
+ Suresh Krishnan's comments on SEND in
https://datatracker.ietf.org/doc/draft-ietf-trill-arp-optimization/ballot/
This review look for SEND and anything unspecified. 

Routing QA reviewer (follow email thread for review)
http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02676.html

Personnel
  Document Shepherd:  Susan Hares (WG co-chair)
  Responsible Area Director: (Alia Atlas)
  WG chairs: Susan Hares and Jon Hudson
  Routing QA Reviewer: Matthew Bocci  (July 2015)

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

a) nits run
b) discussion with authors (see detail in Document quality)
c) Assured that Routing QA review was responded to

(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 - no additional QA reviews outside of routing directorate.
Normal final security-directorate, routing-directorate, GEN-ART, OPS-DIR reviews should be made.

(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 WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No issues to be concerned about. 
Directory assist is critical to standardize to advance TRILL.

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

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

3 IPR disclosures have been filed. The WG was informed regarding the IPR at WG LC.
https://datatracker.ietf.org/ipr/search/?submit=draft
&id=draft-ietf-trill-directory-assist-mechanisms

for LC comments.
https://mailarchive.ietf.org/arch/msg/trill/K1QekixHBxmHjEYzt5IRXaih_0A

Authors knew of no additional IPR
(see mail thread above)
Radia Perlman
https://mailarchive.ietf.org/arch/msg/trill/PJO4Qcc3ciJIjrArdPMIJqruEOI
Linda Dunbar
https://mailarchive.ietf.org/arch/msg/trill/dXH1ZSuxWyrA4T5sWYn5eo9Oogw
Donald Eastlake III
https://mailarchive.ietf.org/arch/msg/trill/Df_BhjKD5q43EQi9CGAcJTgTx6o
Yizhou Li
https://mailarchive.ietf.org/arch/msg/trill/TthWYuP8_KlqiW8DBi-yVEr1C3Y

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

Solid discussion after 3 years of work.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

No threats or conflict over 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.

No nits


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

None needed

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

[rfc7180bis]  - is the only normative reference not at RFC.
It is approved for publication and at the RFC Editor

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

[ARP optimization] -  is in WG, WG LC (2/8 to 2/22/2016)
[[ChannelTunnel]- has past WG LC (5 months, Awaiting QA Review).

(16) Will publication of this document change the status of any
existing RFCs? 
No change to existing RFCs.

(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 has previewed the 8 actions needed for this draft, and
indicated they have approved it.

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

None of the 8 actions this draft suggests require an expert review.

(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 XML code, no BNF rules, no MIB definitions in this draft.

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

The IANA Services Operator has completed its review of draft-ietf-trill-directory-assist-mechanisms-10.txt. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that, upon approval of this document, there are thirteen actions which we must complete.

First, the current draft makes the following request:

IANA will assign a two bit field [bits 1-2 suggested] within the ESADI-Parameter TRILL APPsub-TLV flags for "Push Directory Server Status" (PDSS) and will create a sub-registry in the TRILL Parameters Registry.

IANA Question --> Is this intended to be a range reserved in the TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1 registry located at:

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

If not, what is the name and location of the registry where the range should be reserved for Push Directory Server Status?

Second, a new registry is to be created called the ESADI-Parameter APPsub-TLV Flag Bits registry. This will be a new subregistry in the Transparent Interconnection of Lots of Links (TRILL) Parameters registry located at:

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

The registry will be managed via Standards Action as defined in RFC 5226. There are initial entries in the new subregistry as follows:

Sub-Registry: ESADI-Parameter APPsub-TLV Flag Bits
Registration Procedures: Standards Action
References: [RFC7357] [This document]

Bit Mnemonic Description Reference
--- -------- ----------- ---------
0 UN Supports Unicast ESADI ESDADI [RFC7357]
1-2 PDSS Push Directory Server Status [this document]
3-7 - Available for assignment

Third, in the TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1 registry located at:

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

the reference for the subregistry is to be modified to add [ RFC-to-be ] as a seond refernece for the registry. IANA understands that this is the only action required to meet the request in Action 2 of Section 7.1 of the current draft.

Fourth, in the RBridge Channel Protocols subregistry of the Transparent Interconnection of Lots of Links (TRILL) Parameters registry located at:

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

a single, new channel number is to be assigned as follows:

Protocol: [ TBD-at-registration ]
Description: Pull Directory Services
Reference: [ RFC-to-be ]

Fifth, in the Interested VLANs Flag Bits subregistry of the Transparent Interconnection of Lots of Links (TRILL) Parameters registry located at:

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

a new registration will be made as follows:

Bit: [ TBD-at-registration ]
Mnemonic:
Description: Pull Directory server (PUL)
Reference: [ RFC-to-be ]

IANA notes that the authors suggest bit 18 for this registration.

IANA Question --> Do the authors wish to supply a mnemonic for this registration?

Sixth, in the Interested Labels Flag Bits subregistry also in the Transparent Interconnection of Lots of Links (TRILL) Parameters registry located at:

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

a new registration will be made as follows:

Bit: [ TBD-at-registration ]
Mnemonic:
Description: Pull Directory server (PUL)
Reference: [ RFC-to-be ]

IANA notes that the authors suggest bit 6 for this registration.

IANA Question --> Do the authors wish to supply a mnemonic for this registration?

Seventh, in the Interested VLANs Flag Bits subregistry of the Transparent Interconnection of Lots of Links (TRILL) Parameters registry located at:

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

a new registration will be made as follows:

Bit: [ TBD-at-registration ]
Mnemonic:
Description: No Data (NOD)
Reference: [ RFC-to-be ]

IANA notes that the authors suggest bit 19 for this registration.

IANA Question --> Do the authors wish to supply a mnemonic for this registration?

Eighth, in the Interested Labels Flag Bits subregistry also in the Transparent Interconnection of Lots of Links (TRILL) Parameters registry located at:

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

a new registration will be made as follows:

Bit: [ TBD-at-registration ]
Mnemonic:
Description: No Data (NOD)
Reference: [ RFC-to-be ]

IANA notes that the authors suggest bit 7 for this registration.

IANA Question --> Do the authors wish to supply a mnemonic for this registration?

Ninth, a new registry is to be created called the TRILL Pull Directory QTYPEs registry. This will be a new subregistry in the Transparent Interconnection of Lots of Links (TRILL) Parameters registry located at:

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

The registry will be managed via IETF Review as defined in RFC 5226. There are initial entries in the new subregistry as follows:

Name: TRILL Pull Directory QTYPEs
Registration Procedure: IETF Review
Reference: [this document]

QTYPE Description Reference
----- ----------- -------------------
0 Reserved [ RFC-to-be ]
1 Address query [ RFC-to-be ]
2 Frame query [ RFC-to-be ]
3-4 Unassigned [ RFC-to-be ]
5 Unknown unicast MAC query frame [ RFC-to-be ]
6-14 Unassigned [ RFC-to-be ]
15 Reserved [ RFC-to-be ]

Tenth, a new registry is to be created called the TRILL Pull Directory Errors registry. This will be a new subregistry in the Transparent Interconnection of Lots of Links (TRILL) Parameters registry located at:

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

The registry will be managed via IETF Review as defined in RFC 5226. There are initial entries in the new subregistry as follows:

Err Level Meaning
------ ------- -------
0 - No Error
1 Message Unknown or reserved Query Message field value
2 Message Request Message/data too short
3 Message Unknown or reserved Update Message field value
4 Message Update Message/data too short
5-126 Message Unassigned
127 - Reserved
128 Record Unknown or reserved QUERY Record field value
129 Record QUERY Record truncated
130 Record Address not found
131 Record Unknown or reserved RESPONSE Record field value
132 Record RESPONSE Record truncated
133-254 Record Unassigned
255 - Reserved

Each of the new, initial registrations in the TRILL Pull Directory Errors registry will have a referencee of [ RFC-to-be ].

Eleventh, a new registry is to be created called the Sub-codes for TRILL Pull Directory Errors 1 and 3 registry. It is intended that this be a subregistry of the registry created in step ten above (the TRILL Pull Directory Errors registry). This will be a new subregistry in the Transparent Interconnection of Lots of Links (TRILL) Parameters registry located at:

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

The registry will be managed via Expert Review as defined in RFC 5226. There are initial entries in the new subregistry as follows:

SubErr Field with Error
------ ----------------
0 Unspecified
1 Unknown Ver field value
2 Unknown Type field value
3 Specified Data Label not being served
4-254 Unassigned
255 Reserved

Each of the new, initial registrations in the sub-codes for TRILL Pull Directory Errors 1 and 3 registry will have a referencee of [ RFC-to-be ].

Twelfth, a new registry is to be created called the Sub-codes for TRILL Pull Directory Errors 128 and 131. It is intended that this be a subregistry of the registry created in step ten above (the TRILL Pull Directory Errors registry). This will be a new subregistry in the Transparent Interconnection of Lots of Links (TRILL) Parameters registry located at:

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

The registry will be managed via Expert Review as defined in RFC 5226. There are initial entries in the new subregistry as follows:

SubErr Field with Error
------ ----------------
0 Unspecified
1 Unknown AFN field value
2 Unknown or Reserved QTYPE field value
3 Invalid or inconsistent SIZE field value
4 Invalid frame for QTYPE 2, 3, 4, or 5
5-254 Unassigned
255 Reserved

Each of the new, initial registrations in the Sub-codes for TRILL Pull Directory Errors 128 and 131 will have a referencee of [ RFC-to-be ].

Thirteenth, in the TRILL Multicast Addresses also n the Transparent Interconnection of Lots of Links (TRILL) Parameters registry located at:

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

a new registration will be made as follows:

Address: [ TBD-at-registration ]
Description: TRILL-ES-IS
Reference: [ RFC-to-be ]

IANA notes that the authors suggest a value of 01-80-C2-00-00-47 for this registration.

The IANA Services Operator understands that these thirteen actions are the only ones required to be completed upon approval of this document.
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 Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: trill-chairs@ietf.org, draft-ietf-trill-directory-assist-mechanisms@ietf.org, trill@ietf.org, shares@ndzh.com, akatlas@gmail.com
Reply-To: ietf@ietf.org
Sender:
Subject: EXTENSION OF Last Call:  (TRILL: Edge Directory Assist Mechanisms) 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: Edge Directory Assist Mechanisms'
  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 2017-01-09. 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


  This document describes mechanisms for providing directory service to
  TRILL (Transparent Interconnection of Lots of Links) edge switches.
  The directory information provided can be used in reducing multi-
  destination traffic, particularly ARP/ND and unknown unicast
  flooding. It can also be used to detect traffic with forged source
  addresses.






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

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

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2524/
  https://datatracker.ietf.org/ipr/2372/
  https://datatracker.ietf.org/ipr/2039/

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: trill-chairs@ietf.org, draft-ietf-trill-directory-assist-mechanisms@ietf.org, trill@ietf.org, shares@ndzh.com, akatlas@gmail.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (TRILL: Edge Directory Assist Mechanisms) 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: Edge Directory Assist Mechanisms'
  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 2017-01-02. 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


  This document describes mechanisms for providing directory service to
  TRILL (Transparent Interconnection of Lots of Links) edge switches.
  The directory information provided can be used in reducing multi-
  destination traffic, particularly ARP/ND and unknown unicast
  flooding. It can also be used to detect traffic with forged source
  addresses.






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

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

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2524/
  https://datatracker.ietf.org/ipr/2372/
  https://datatracker.ietf.org/ipr/2039/

template for shepherd write (version: 2/24/2012)
Date of review: 2/8/2016

1) type of RFC: Proposed standard (indicated on title page)
2) Shepherd: Susan Hares
3) WG chairs: Jon Hudson and Susan Hares

Technical Summary

  This document describes mechanisms for providing directory service to
  TRILL (Transparent Interconnection of Lots of Links) edge switches.
  The directory information provided can be used in reducing multi-
  destination traffic, particularly ARP/ND and unknown unicast
  flooding. It can also be used to detect traffic with forged source
  addresses.  Directory Service can utilize either a push or a pull mechanism.


Working Group Summary

This document is the result of 3 years of intensive discussion.
The WG consensus was complete even if the WG discussion at the
end of the three years was "Time to send this to IESG".

Document Quality
The Shepherd's review is at this point
https://mailarchive.ietf.org/arch/msg/trill/HZ5p1GTo_2vJT6xOPPDyVB15P3Q
Authors response:
https://mailarchive.ietf.org/arch/msg/trill/ezH1lwbqOwTBuC4h_WtcZ_QNaxw
Shepherd's review of changes and acceptance of changes (minus 2 editorial nits)
https://mailarchive.ietf.org/arch/msg/trill/oQjR3jwAKkayHvPRdKznCmOf8u4
Final resolution by Authors:
https://mailarchive.ietf.org/arch/msg/trill/FkSuXx4ugHIzYsuVIhE3xlOizZM

Routing QA reviewer (follow email thread for review)
http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02676.html

Personnel

  Document Shepherd:  Susan Hares (WG co-chair)
  Responsible Area Director: (Alia Atlas)
  WG chairs: Susan Hares and Jon Hudson
  Routing QA Reviewer: Matthew Bocci  (July 2015)

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

a) nits run
b) discussion with authors (see detail in Document quality)
c) Assured that Routing QA review was responded to

(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 - no additional QA reviews outside of routing directorate.
Normal final security-directorate, routing-directorate, GEN-ART, OPS-DIR reviews should be made.

(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 WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No issues to be concerned about. 
Directory assist is critical to standardize to advance TRILL.

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

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

3 IPR disclosures have been filed. The WG was informed regarding the IPR at WG LC.
https://datatracker.ietf.org/ipr/search/?submit=draft
&id=draft-ietf-trill-directory-assist-mechanisms

for LC comments.
https://mailarchive.ietf.org/arch/msg/trill/K1QekixHBxmHjEYzt5IRXaih_0A

Authors knew of no additional IPR
(see mail thread above)
Radia Perlman
https://mailarchive.ietf.org/arch/msg/trill/PJO4Qcc3ciJIjrArdPMIJqruEOI
Linda Dunbar
https://mailarchive.ietf.org/arch/msg/trill/dXH1ZSuxWyrA4T5sWYn5eo9Oogw
Donald Eastlake III
https://mailarchive.ietf.org/arch/msg/trill/Df_BhjKD5q43EQi9CGAcJTgTx6o
Yizhou Li
https://mailarchive.ietf.org/arch/msg/trill/TthWYuP8_KlqiW8DBi-yVEr1C3Y

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

Solid discussion after 3 years of work.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

No threats or conflict over 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.

No nits


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

None needed

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

[rfc7180bis]  - is the only normative reference not at RFC.
It is approved for publication and at the RFC Editor

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

[ARP optimization] -  is in WG, WG LC (2/8 to 2/22/2016)
[[ChannelTunnel]- has past WG LC (5 months, Awaiting QA Review).

(16) Will publication of this document change the status of any
existing RFCs? 
No change to existing RFCs.

(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 has previewed the 8 actions needed for this draft, and
indicated they have approved it.

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

None of the 8 actions this draft suggests require an expert review.

(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 XML code, no BNF rules, no MIB definitions in this draft.