Hi Alvaro, On Wed, Feb 7, 2018 at 12:28 PM, Alvaro Retana <[email protected]> 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 +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA [email protected] _______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
