John Scudder has entered the following ballot position for draft-ietf-bess-pbb-evpn-isid-cmacflush-08: 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-pbb-evpn-isid-cmacflush/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - General: I'm taking it on faith that the flush procedures are properly specified in one of the underlying specs. This one doesn't, it just is an overlay that says "do the flush procedure but with this different trigger". - General: G.8032 should be at least an Informative reference. - Section 1.1: Terms defined but never used, or used only once (so could be inline) - B-Component (used only once) - vES (never used) - I-Component (only used once) - RD and RT are used only once, too - Section 2(d), It's not obvious to me what "double flushing" means (and I do know something about route reflectors). - Section 3, "The MAC Mobility extended community is used as in [RFC7623], where a delta in the sequence number between two updates for the same B-MAC/I-SID will be interpreted as a C-MAC-flush notification for the corresponding B-MAC and I-SID", it seems to me that "a delta in the sequence number" is a more casual description than is warranted? Looking at RFC 7423, it appears the sequence number has to be incremented (modulo sequence wrap), not just different (which is what "delta" implies). I guess a simple fix would be s/a delta/an increment/. (Occurs again in Section 4.2, and again in Section 4.3. Just grep for "delta".) - Section 4, where you write "Enabling or disabling I-SID-based C-MAC-flush SHOULD be an administrative choice on the system that MAY be configured per I-SID (I-Component). When enabled on a PE:", do you really mean the MAY to be interpreted in the sense of RFC 2119, i.e. it's completely optional? Or do you mean "may"? - Section 5(e), "The solution can coexist in a network with systems supporting or not supporting this specification." I guess the coexistence with non-supporting systems is that they just ignore the new style of route, and have to age out the MACs the old-fashioned way (with concomitant loss of traffic)? _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
