Alvaro Retana has entered the following ballot position for draft-ietf-trill-address-flush-05: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-trill-address-flush/ ---------------------------------------------------------------------- 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. (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. (2a) Other descriptions (type 1,2,6) just talk about ignoring (not discarding). Is there an intended difference in the behavior? (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. _______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
