All good, many thanks Jorge 😁 A bientôt;
Pascal > Le 23 oct. 2023 à 13:22, Jorge Rabadan (Nokia) <jorge.raba...@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 <nore...@ietf.org> > Date: Monday, August 7, 2023 at 8:24 AM > To: int-...@ietf.org <int-...@ietf.org> > Cc: bess@ietf.org <bess@ietf.org>, > draft-ietf-bess-pbb-evpn-isid-cmacflush....@ietf.org > <draft-ietf-bess-pbb-evpn-isid-cmacflush....@ietf.org>, last-c...@ietf.org > <last-c...@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
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
