PBB-EVPN ISID-based C-MAC-Flush
draft-ietf-bess-pbb-evpn-isid-cmacflush-09

# Éric Vyncke, INT AD, comments for draft-ietf-bess-pbb-evpn-isid-cmacflush-08

Thank you for the work put into this document. This is a very specific area of work and the text is not easy to read for a non expert. So, I was happy to rely on the Internet directorate review below by Pascal.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Matthew Bocci for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. 

Other thanks to Pascal Thubert, the Internet directorate reviewer (at my request), please consider this int-dir review as if it was mine:
https://datatracker.ietf.org/doc/draft-ietf-bess-pbb-evpn-isid-cmacflush/reviewrequest/17846/

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS

## Abstract

No need for action, but I have rarely seen such an acronym-dense abstract, it is therefore hard to read.

## G.8032

G.8032 should be an informative reference (this would be DISCUSS level issue if the reference was normative).

## Scalability

Should there be some text about the scalability issues ? I.e., MAC addresses move (Wi-Fi roaming) and are changing (cfr MADINAS WG).

Thank you to Klaas Wierenga for the SECDIR review.

- 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)?

# GEN AD review of draft-ietf-bess-pbb-evpn-isid-cmacflush-08

CC @larseggert

Thanks to Joel Halpern for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/CBzsxEwRDvcvkn70BvytwrKRLEg).

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

The term "B-Component" is in the glossary, but isn't used in this document.  Same with "CE" and "vES".

I find the use of SHOULD around an administrative option to be peculiar.  This is normally associated with interoperability requirements, but even setting that aside, let's say I decide to implement this in a way that the solution overall or the capability defined in Section 4 simply can't be enabled or disabled.  Is the implementation still viable?  I also concur with John's point that the SHOULD-MAY combination is similarly strange.

I fully agree with Eric's "This is a very specific area of work and the text is not easy to read for a non expert. I read it, but was somewhat baffled by the quantity of acronyms and terminology, and to I too relied on Pascal Thubert's IntDir review (https://datatracker.ietf.org/doc/review-ietf-bess-pbb-evpn-isid-cmacflush-08-intdir-telechat-thubert-2023-08-07/) to help choose my position.