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

[Donald Eastlake <[e-mail]>]

Version -06 posted as requested.

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

On Sun, Mar 18, 2018 at 7:16 AM, Alia Atlas <[e-mail]> wrote:

> Donald,
>
> Could you please submit this ?
>
> Thanks,
> Alia
>
> On Wed, Mar 14, 2018 at 8:32 PM, Donald Eastlake <[e-mail]> wrote:
>
>> 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
>> <https://maps.google.com/?q=155+Beaver+Street,+Milford,+MA+01757+USA&entry=gmail&source=g>
>>  [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] <(508)%20333-2270> (cell)
>> >  155 Beaver Street, Milford, MA 01757 USA
>> <https://maps.google.com/?q=155+Beaver+Street,+Milford,+MA+01757+USA&entry=gmail&source=g>
>> >  [e-mail]
>>
>> _______________________________________________
>> trill mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/trill
>>
>>
>