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

[Donald Eastlake <[e-mail]>]

Hi Alvaro,

Attached is a candidate -06 version of draft-ietf-trill-address-flush
(my internal version 39) intended to resolve your comments. Also
attached is a diff against the currently posted -05. Can you take a
looks and see if your comments are satisfied?

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


On Thu, Feb 8, 2018 at 11:39 AM, Donald Eastlake <[e-mail]> wrote:
> 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]