Re: [Last-Call] Intdir telechat review of draft-ietf-bess-pbb-evpn-isid-cmacflush-08

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

Hi Pascal,

Thank you very much for reviewing.
Your comments are addressed in version 09.
Some responses to your comments below:

Please indicate how the CE can know if the PW failure is not due to the PE
failure, in which case extending the Customer MAC flush solution in RFC7623
seems more efficient as all I-SIDs with link / PW starting there are affected.
And how the double flush in avoided in the case of a non-null ESI with this
spec on as well.

[Jorge] we improved the introduction, hopefully it clarifies those points now.

I found this
"
When I-SID-based C-MAC-flush is disabled, the PE will follow the [RFC7623]
procedures for C-MAC-flush. " but it does not answer either of the above. e.g.,
does the reciprocal of the above apply too? or can they be both on?

[Jorge] good point. We replaced the sentence with:
>The PE MUST follow the RFC7623 procedures for C-MAC-flush. This specification brings some additional procedures when I-SID-based C-MAC-flush is enabled.

I'd have thought that upon loss of connectivity with PE3, CE3 enables the PW to[
PE4 and tells PE4 to send the update. Now it seems that the main player of this
spec is actually PE4 and that it's death is reported some other way. If that's
correct, saying it earlier would have saved me a headache ;)

[Jorge] hopefully the introduction is now clearer.

The following are minor issues (typos, misspelling, minor text improvements)
with the document:

First use (in intro) of "Ethernet Segments" add "(ES)" since ES and ESI are
used later. On second use (with multi home) please indicate whether that is
equivalent to non-null ESI and virtual ES since they seem to be used
interchangeably later.

[Jorge] ok, text added.

"
Since there are no multi-homed ES defined, the PEs keep their Attachment
Circuits active as long as the physical connectivity is established and the CEs
are responsible for managing the redundancy, avoiding loops and providing
per-I-SID load balancing to the PBB-EVPN network. " This makes sense but a
reference to a spec that explains that in details (: to the dumb reader :)
would be appreciated. Is this all in RFC7623?

[Jorge] no, not really. Added reference specs describing G.8032 and A/S PWs.

"
For instance, CE2 will block its link to CE1 and CE3 will block its forwarding
path to PE4. " I understand that's the normal before-failure condition, like
having the ring open between CE1 and CE2. Suggestion:

"
For instance, in normal conditions, CE2 will block its link to CE1 and CE3 will
block its forwarding path to PE4. "


[Jorge] done

On first use of the BMAC/X format please clarify that it means BMAC/ISID. This
appears later but without clarification.

[Jorge] it is clarified now

Thx
Jorge

From: Pascal Thubert via Datatracker <[e-mail]>
Date: Monday, August 7, 2023 at 8:24 AM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Intdir telechat review of draft-ietf-bess-pbb-evpn-isid-cmacflush-08


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.



Reviewer: Pascal Thubert
Review result: Ready with Nits

I am an assigned INT directorate reviewer for
draft-ietf-bess-pbb-evpn-isid-cmacflush-08. These comments were written
primarily for the benefit of the Internet Area Directors. Document editors and
shepherd(s) should treat these comments just like they would treat comments
from any other IETF contributors and resolve them along with any other Last
Call comments that have been received. For more details on the INT Directorate,
see https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.

Based on my review, if I was on the IESG I would ballot this document as NO
OBJECTION.

The following are other issues I found with this document that SHOULD be
corrected before publication:

Please indicate how the CE can know if the PW failure is not due to the PE
failure, in which case extending the Customer MAC flush solution in RFC7623
seems more efficient as all I-SIDs with link / PW starting there are affected.
And how the double flush in avoided in the case of a non-null ESI with this
spec on as well.


I found this
"
When I-SID-based C-MAC-flush is disabled, the PE will follow the [RFC7623]
procedures for C-MAC-flush. " but it does not answer either of the above. e.g.,
does the reciprocal of the above apply too? or can they be both on?

I'd have thought that upon loss of connectivity with PE3, CE3 enables the PW to
PE4 and tells PE4 to send the update. Now it seems that the main player of this
spec is actually PE4 and that it's death is reported some other way. If that's
correct, saying it earlier would have saved me a headache ;)

The following are minor issues (typos, misspelling, minor text improvements)
with the document:

First use (in intro) of "Ethernet Segments" add "(ES)" since ES and ESI are
used later. On second use (with multi home) please indicate whether that is
equivalent to non-null ESI and virtual ES since they seem to be used
interchangeably later.

"
Since there are no multi-homed ES defined, the PEs keep their Attachment
Circuits active as long as the physical connectivity is established and the CEs
are responsible for managing the redundancy, avoiding loops and providing
per-I-SID load balancing to the PBB-EVPN network. " This makes sense but a
reference to a spec that explains that in details (: to the dumb reader :)
would be appreciated. Is this all in RFC7623?

"
For instance, CE2 will block its link to CE1 and CE3 will block its forwarding
path to PE4. " I understand that's the normal before-failure condition, like
having the ring open between CE1 and CE2. Suggestion:

"
For instance, in normal conditions, CE2 will block its link to CE1 and CE3 will
block its forwarding path to PE4. "

On first use of the BMAC/X format please clarify that it means BMAC/ISID. This
appears later but without clarification.