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

[Donald Eastlake <[e-mail]>]

Hi Alvaro,

On Wed, Feb 7, 2018 at 12:28 PM, Alvaro Retana <[e-mail]> wrote:
> Alvaro Retana has entered the following ballot position for
> draft-ietf-trill-address-flush-05: No Objection
>
> ...
>
> ----------------------------------------------------------------------
> 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.

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.

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

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

> (2a) Other descriptions (type 1,2,6) just talk about ignoring (not discarding).
>  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.)

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

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

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]