Subject: [trill] Alvaro Retana's No Objection on draft-ietf-trill-address-flush-05: (with COMMENT)

From: Alvaro Retana <[email-masked]>
Date: Wed, 07 Feb 2018 09:28:46 -0800

Alvaro Retana has entered the following ballot position for
draft-ietf-trill-address-flush-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-address-flush/

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

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 8 Feb 2018 11:39:11 -0500

Hi Alvaro,

On Wed, Feb 7, 2018 at 12:28 PM, Alvaro Retana <[email-masked]> wrote:
> ...

I suppose some wording could be added but the idea is that the VLAN
Block Only Case is part of the basic message and always has to be
implemented, as opposed to the extensible list of TLV types. The
message is structured so that you can't use both the VLAN Block Only
Case and the extensible TLV structure to specify VLANs at the same
time. The VLAN Block Only Case is expected to be common and
corresponds more closely to deployed code.

> doesn't qualify dropping based on the type support.

If the Type is not implemented, then how would you know that the
length is not valid? How would you currently code a length validity
check for types to be specified in the future as part of the
extensibility of the message? But, since there is a length field, you
can always skip over a TLV you don't understand. The qualification
based on type support should be there for Type 5 also. (Of course, in
the real world, I think inconsistent Address Flush message type
support in a TRILL campus will be very rare.)

>  Is there an intended difference in the behavior?

There is no intended difference between "ignoring" and "discarding" an
Address Flush message. (Types 1, 2, and 6 are the mandatory to support
types so there is no conditional on support.)

> not clear to me whether unicast packets (mentioned later) should also have the

Yes, probably throwing in "including unicast Address Flush messages"
would clarify.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]