Re: [bess] John Scudder's No Objection on draft-ietf-bess-pbb-evpn-isid-cmacflush-08: (with COMMENT)

["Jorge Rabadan (Nokia)" <[e-mail]>]

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 <[e-mail]>
Date: Friday, August 4, 2023 at 6:27 PM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Matthew Bocci (Nokia) <[e-mail]>, Matthew Bocci (Nokia) <[e-mail]>
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”