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

All good, many thanks Jorge 😁

A bientôt;

Pascal

> Le 23 oct. 2023 à 13:22, Jorge Rabadan (Nokia) <jorge.rabadan@nokia.com> a écrit :
> 
> 
> 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 <noreply@ietf.org>
> Date: Monday, August 7, 2023 at 8:24 AM
> To: int-dir@ietf.org <int-dir@ietf.org>
> Cc: bess@ietf.org <bess@ietf.org>, draft-ietf-bess-pbb-evpn-isid-cmacflush.all@ietf.org <draft-ietf-bess-pbb-evpn-isid-cmacflush.all@ietf.org>, last-call@ietf.org <last-call@ietf.org>
> 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.
> 
> _______________________________________________
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess