Transparent Interconnection of Lots of Links (TRILL): Address Flush Message
draft-ietf-trill-address-flush-06

[Ballot comment]
Thanks to everyone who contributed to writing this document.

I'm concerned that the interaction between the various extensible Address Flush
message TLVs isn't very clearly spelled out. As far as I can tell, the text that
attempts to describe the interactions is:

>    If the set of MAC addresses accumulated from parsing the address
>  flush message is null, the message applies to all MAC addresses.
>    If the flag indicating the presence of an All Data Labels TLV is
>  true, then the address flush message applies to all Data Labels and
>  the set of Data Labels and block of Data labels specified has no
>  effect. If the flag indicating the presence of an All Data Labels TLV
>  is false, then the address flush messages applies only to the set of
>  Data Labels accumulated from parsing the message; if that set is
>  null, the address flush message does nothing.

Based on this (and the fact that their implementation is optional), I infer
that the MAC address TLVs are intended to further restrict the addresses
indicated by TLV types 1 through 5, rather than expand upon them. I'm less
sure about whether they have any impact on Type 6. I would expect that they
do, but the text above ("applies to all Data Labels") kind of sounds like they
don't.

What would seem to make sense here (inasmuch as it provides maximal flexibility)
is:

if (TLV7 ∪ TLV8 = {})
  Addresses to Flush = (TLV1 ∪ TLV2 ∪ TLV3 ∪ TLV4 ∪ TLV5 ∪ TLV6)
else
  Addresses to Flush = (TLV1 ∪ TLV2 ∪ TLV3 ∪ TLV4 ∪ TLV5 ∪ TLV6) ∩ (TLV7 ∪ TLV8)

If that's the intention, I think the normative explanation needs to be clearer.
If that's not the intention, I sill think the normative explanation needs to be
clearer.

My remaining comments are editorial.
---------------------------------------------------------------------------

Please expand the following acronyms upon first use and in the title;
see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.

- TRILL
- TC
- TCN
- MSTP

While the following terms are defined in cited documents, you may wish to also
consider expanding them in this document's acronym list for the convenience of
the reader:

- MAC
- FCS

Finally, please explain the use of "RB1" in the Introduction.

---------------------------------------------------------------------------

§1:

>  Another example is based on Appendix A.3 of [RFC6325] ("Wiring Closet
>  Topology") presents a bridged LAN connected to a TRILL network via
>  multiple RBridge ports.

This should be either:

  Another example, based on Appendix A.3 of [RFC6325] ("Wiring Closet
  Topology"), presents a bridged LAN connected to a TRILL network via
  multiple RBridge ports.

or...

  Another example is based on Appendix A.3 of [RFC6325] ("Wiring Closet
  Topology"), which presents a bridged LAN connected to a TRILL network
  via multiple RBridge ports.

---------------------------------------------------------------------------

§1.1:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in [RFC2119].

This document makes use of lowercase versions of these terms as well; please
consider using the RFC 8174 boilerplate.

---------------------------------------------------------------------------

§2.2:

>  VLANs/FGLs if it occurs in any TLV in the address flush message. A
>  MAC addresses might be indicated more than once due to overlapping

"A MAC address..." or "MAC addresses..."


---------------------------------------------------------------------------

§2.2:

>  MAC addresses if it occurs in any TLV in the address flush message.
>    If the set of MAC addresses accumulated from parsing the address
>  flush message is null, the message applies to all MAC addresses.
>    If the flag indicating the presence of an All Data Labels TLV is
>  true, then the address flush message applies to all Data Labels and

The staggered indenting here looks a bit odd. Were these intended to be a
bulleted list?

[Ballot comment]
I appreciate the detail in the shepherd's writeup concerning the initial IPR disclosure. However, another  (third party) disclosure was entered yesterday. I will leave this to Alia to decide, but I wonder if the WG shouldn't have some time to consider that disclosure prior to the IESG, and perhaps to give the first party for that disclosure a chance to disclose terms.

[Ballot comment]
I have some non-blocking comments/questions:

(1) Why are the 2 VLAN Block encodings needed?  More important, when should each be used?  Section 2.2 says that "All RBridges implementing the Address Flush RBridge Channel message MUST implement types 1 and 2, the VLAN types...", but I didn't see anything about the VLAN Block Only Case (2.1).  I'm wondering if there will be cases where the support won't match and the message will then be ineffective.

(2) In the 2.2.* sections, the description of some of the TLVs says (when the Length is incorrect) that "...the Address Flush message MUST be discarded if the receiving RBridge implements Type x".  What if that type is not supported -- I would assume you still want to discard?  BTW, the Type 5 description doesn't qualify dropping based on the type support.

(2a) Other descriptions (type 1,2,6) just talk about ignoring (not discarding).  Is there an intended difference in the behavior?

(3) Section 2 says that "Address Flush protocol messages are usually sent as multi-destination packets...Such messages SHOULD be sent at priority 6".  It is not clear to me whether unicast packets (mentioned later) should also have the same priority.

[Ballot comment]
I have some non-blocking comments/questions:

(1) Why are the 2 VLAN Block encodings needed?  More important, when should each be used?  Section 2.2 says that "All RBridges implementing the Address Flush RBridge Channel message MUST implement types 1 and 2, the VLAN types...", but I didn't see anything about the VLAN Block Only Case (2.1).  I'm wondering if there will be cases where the support won't match and the message will then be ineffective.

(2) In the 2.2.* sections, the description of some of the TLVs says (when the Length is incorrect) that "...the Address Flush message MUST be discarded if the receiving RBridge implements Type x".  What if that type is not supported -- I would assume you still want to discard?  BTW, the Type 5 description doesn't qualify dropping based on the type suport.

(2a) Other descriptions (type 1,2,6) just talk about ignoring (not discarding).  Is there an intended difference in the behavior?

(3) Section 2 says that "Address Flush protocol messages are usually sent as multi-destination packets...Such messages SHOULD be sent at priority 6".  It is not clear to me whether unicast packets (mentioned later) should also have the same priority.

[Ballot comment]
This is probably a dumb question but I notice that there's no
filtering here for for example, VLAN IDs which the sending agent
doesn't seem to be relevant for. Can you explain why that's not
needed/desirable?

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

The IANA Services Operator has completed its review of draft-ietf-trill-address-flush-04. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of [ RFC-to-be ], there are two actions which we must complete.

First, in the RBridge Channel Protocols registry on the Transparent Interconnection of Lots of Links (TRILL) Parameters registry page located at:

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

a single, new protocol is to be registered as follows:

Protocol: [ TBD-at-Registration ]
Description: Address Flush
Reference: [ RFC-to-be ]

We note that the value to be used in this registration should come from the Standards Action range of the registry.

Second, a new registry is to be created called the TRILL Address Flush TLV Types registry. The new registry will be located on the Transparent Interconnection of Lots of Links (TRILL) Parameters registry page located at:

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

The regsitration procedure for the new registry will be IETF Review.

There are initial registrations in the new registry as follows:

Type Description Reference
-----+-------------------+-------------
0 Reserved [ RFC-to-be ]
1 Blocks of VLANs [ RFC-to-be ]
2 Bit Map of VLANs [ RFC-to-be ]
3 Blocks of FGLs [ RFC-to-be ]
4 List of FGLs [ RFC-to-be ]
5 Bit Map of FGLs [ RFC-to-be ]
6 All Data Labels [ RFC-to-be ]
7 MAC Address List [ RFC-to-be ]
8 MAC Address Blocks [ RFC-to-be ]
9-254 Unassigned
255 Reserved [ RFC-to-be ]

The IANA Services Operator understands that these are the only actions required to be completed upon approval of [ RFC-to-be ].

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 the list of actions that will be performed.


Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-02-05):

From: The IESG
To: IETF-Announce
CC: Susan Hares , akatlas@gmail.com, trill-chairs@ietf.org, trill@ietf.org, draft-ietf-trill-address-flush@ietf.org, shares@ndzh.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (TRILL: Address Flush Message) 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: Address
Flush Message'
  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 2018-02-05. 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 TRILL (TRansparent Interconnection of Lots of Links) protocol, by
  default, learns end station addresses from observing the data plane.
  In particular, it learns local MAC addresses and edge switch port of
  attachment from the receipt of local data frames and learns remote
  MAC addresses and edge switch of attachment from the decapsulation of
  remotely sourced TRILL Data packets.

  This document specifies a message by which a TRILL switch can
  explicitly request other TRILL switches to flush certain MAC
  reachability learned through the decapsulation of TRILL Data packets.
  This is a supplement to the TRILL automatic address forgetting and
  can assist in achieving more rapid convergence in case of topology or
  configuration change.







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

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

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

  https://datatracker.ietf.org/ipr/3114/

(1) Type of RFC: Proposed Standard

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  The TRILL (TRansparent Interconnection of Lots of Links) protocol,
  by default, learns end station addresses from observing the data
  plane.  In particular, it learns local MAC addresses and edge
  switch port of attachment from the receipt of local data frames and
  learns remote MAC addresses and edge switch of attachment from the
  decapsulation of remotely sourced TRILL Data packets.

  This document specifies a message by which a TRILL switch can
  explicitly request other TRILL switches to flush certain MAC
  reachability learned through the decapsulation of TRILL Data
  packets.  This is a supplement to the TRILL automatic address
  forgetting and can assist in achieving more rapid convergence in
  case of topology or configuration change.

Working Group Summary

  Was there anything in WG process that is worth noting? For example,
  was there controversy about particular points or were there
  decisions where the consensus was particularly rough?

No.  This draft is part of a package of directory/ARP services
for TRILL.  Flushing unused MAC learned MAC addresses is key to
keeping the bridge-router function scalable. A late IPR disclosure
required a second WG Last Call.


Document Quality

  Are there existing implementations of the protocol?

  Huawei has implemented a subset of this protocol.

Reviews: RTG-DIR and shepherd did reviews in 2016-2017.

Personnel

  Document Shepherd: Susan Hares 
  RTG-DIR reviewer: Henning Rogge
  Responsible AD: Alia Atlas

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

Adoption call (4/11/2016 to 4/25/2016)
https://mailarchive.ietf.org/arch/msg/trill/J_MMPmp6fqqsXJ1Tmf9N7fYZPQc

Adoption (4/11/2016 to 4/25/2106) notice
https://mailarchive.ietf.org/arch/msg/trill/RqphjVT29mX4L2rYh1VYXC10UF4

RTG-DIR: Henning Rogge (9/16/2016)
https://mailarchive.ietf.org/arch/search/?email_list=trill&q=address-flush
Response to review:  (12/9/2016)  Donald Eastlake
https://mailarchive.ietf.org/arch/msg/trill/5G_JIxbuhIDNCwKY283QpiKCOKg
Discussion  by Henning Rogge: and approval:
https://mailarchive.ietf.org/arch/search/?email_list=trill&q=address-flush

WG LC (1/13 -1/27/2017)
https://www.ietf.org/mail-archive/web/trill/current/msg07653.html

Shepherd's first review (1/14/2017)
https://mailarchive.ietf.org/arch/msg/trill/KU8sLVy_YPZADCS9AmnHByF-PeY
Response to Shepherd's review (
https://mailarchive.ietf.org/arch/msg/trill/-ApvkOVrimrvn9rMQxhSB-ebwGU
Released document:
https://mailarchive.ietf.org/arch/msg/trill/kHD7XnYZ26emISpJeg7SP5sUPeE

1st WG LC (no consensus )
https://mailarchive.ietf.org/arch/msg/trill/sf1XUZ5cbLXOaDI4uxljc4sjyQY

2nd WG LC (10/2 to 10/16)
https://mailarchive.ietf.org/arch/msg/trill/CU8SKJO5xv-_dqW0FryDLfDJb3U

Passed WG LC :
https://mailarchive.ietf.org/arch/msg/trill/J67-56TDzGQAT6NZze8OImfPhl4

IPR call for address flush
https://www.ietf.org/mail-archive/web/trill/current/msg07990.html
Message regarding WG consensus to forward to the IESG
https://mailarchive.ietf.org/arch/msg/trill/pTU72XebYX0YwLTKzmex0lvpwfQ


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No. There has been careful review as documented above.

(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 - the concept of address flush is utlized in MPLS and other
layer 2.5 protocol suites.

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

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

Yes. After initial author confirmations, an IPR disclosure was filed
and new confirmations were requested from the authors. Those
confirmations have been posted as follows:
  Weiguo Hao
https://www.ietf.org/mail-archive/web/trill/current/msg07991.html
  Donald Eastlake
https://www.ietf.org/mail-archive/web/trill/current/msg07993.html
  Yizhou Li
https://www.ietf.org/mail-archive/web/trill/current/msg07997.html
  Mohammed Umair
https://www.ietf.org/mail-archive/web/trill/current/msg07994.html

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

One IPR disclosure was filed late in the process. As a result, a new
WG Last Call was issued which demonstrated there was still a WG
consensus in favor of publishing the draft.
  IPR call for address flush
https://www.ietf.org/mail-archive/web/trill/current/msg07990.html
Closing of IPR call
https://mailarchive.ietf.org/arch/msg/trill/pTU72XebYX0YwLTKzmex0lvpwfQ


(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. Most of the discussion occurred at meetings where this draft
was presented. There is a clear consensus on the mailing list with no
opposition.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

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

No formal 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?

All references are RFCs.

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

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No. This draft proposes new functionality.

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

This draft requests:

1) Address Flush RBridge Channel Protocol number from the range of
  RBridge Channel protocols allocated by Standards Action [RFC7178],
  and

2) A TRILL Address Flush TLV Types registry on the TRILL Parameters
  web page indented after the RBridge Channel Protocols registry.
  The Table in section 2.2 on page 9
  (draft-ietf-trill-address-flush-04.txt) has the initial values.
  This registry is IETF Review.

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

IETF-Expert Review for TRILL Address Flush TLV Types registry.

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

None needed.