Hi John, Thanks for the review. Your comments have been addressed in version 09.
Please see in-line. Thx Jorge From: John Scudder via Datatracker <[email protected]> Date: Friday, August 4, 2023 at 6:27 PM To: The IESG <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, Matthew Bocci (Nokia) <[email protected]>, Matthew Bocci (Nokia) <[email protected]> Subject: John Scudder's No Objection on draft-ietf-bess-pbb-evpn-isid-cmacflush-08: (with COMMENT) CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. 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". [Jorge] that is precisely the intent. RFC7623 specifies the technology and how C-MACs are flushed. This document is a delta of that. - General: G.8032 should be at least an Informative reference. [Jorge] added, thanks - 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 [Jorge] all fixed, thanks. - Section 2(d), It's not obvious to me what "double flushing" means (and I do know something about route reflectors). [Jorge] this is really a leftover from old discussions that used other alternatives for C-MAC flush. I don’t think the double flushing discussion was due to the RR. I changed the text to the following (to avoid confusion): “The solution MUST provide a reliable C-MAC-flush notification in PBB-EVPN networks that use Route-Reflectors (RRs). MAC flushing needs to be provided to all affected I-SIDs in spite of the BGP flush notification messages being aggregated at the RR.” - 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".) [Jorge] it is a subtle but very good point. I fixed it in all the occurrences. Thanks. - 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"? [Jorge] it really meant MAY… we tried to clarify by adding the following, let us know if it helps: “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, Service Instance Component), as opposed to being configured for all I-SIDs.” - 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)? [Jorge] Yes, ignore and follow RFC7623, which provides c-mac flush for Ethernet Segments but not for other redundant connections. I completed the sentence as follows: “The solution can coexist in a network with systems supporting or not supporting this specification. Non-supporting systems ignore the B-MAC/I-SID routes, however they still follow the C-MAC-flush procedures in RFC7623”
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
