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

[Donald Eastlake <[e-mail]>]

Hi Adam,

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 Fri, Feb 9, 2018 at 11:42 AM, Donald Eastlake <[e-mail]> wrote:
> Hi Adam,
>
> On Wed, Feb 7, 2018 at 11:30 PM, Adam Roach <[e-mail]> wrote:
>> Adam Roach has entered the following ballot position for
>> draft-ietf-trill-address-flush-05: No Objection
>>
>> ...
>>
>> ----------------------------------------------------------------------
>> 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.
>
> The TLVs are all parsed accumulated a possibly null set of Data
> Labels, an "All Data Labels flag", and a possibly null set of MAC
> addresses.
>
>> 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.
>
> That's right.
>
>> 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.
>
> Type 6 only affects the Data Labels that are being flushed. It has no
> effect on the set of MAC addresses which set defaults to "all".
>
>> 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)
>
> That's correct but not complete. If the set of Data Labels indicated
> by any of TLV1 though TLV5 that are present is null, the the Address
> Flush applies to the Data Label after the TRILL Header and Inner MAC
> addresses. It also seems quite confusing to have TLV7 and 8 as if they
> were the same sort of thing as the other TLVs when they are MAC
> addresses and the others all relate to .
>
> Every entry that is flushed consists of a nickname, a Data Label, and
> a MAC address. Nicknames are handled the same way for both the VLAN
> Block only case and the extensible case. The complete set of entries
> that is flushed is the cross product of a set of nicknames, a set of
> Data Labels, and a set of MAC addresses, where the set of Data Labels
> and/or MAC addresses can be "all".
>
>> 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.
>
> We'll see what we can do to clarify.
>
>> My remaining comments are editorial.
>> ---------------------------------------------------------------------------
>
> I'm fine with the changes below and have provided and explanation of "RB1".
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   [phone] (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [e-mail]
>
>> 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.
>
> It's use in this case is pretty much non-existent... :-) A typical
> style in TRILL document is to say "A TRILL switch RB1 ..." Then later
> you can just reference RB1 rather than having to talk about it in some
> more complex say. (Usually there is also an RB2, RB3, ... but not
> always.) Since the "RB1" is never referenced again in this case, it
> can just be deleted.
>
>> ---------------------------------------------------------------------------
>>
>> §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?