Hi Roman, Thanks for the review. Please see the resolution of your comments in-line with [jorge].
Thx Jorge From: Roman Danyliw via Datatracker <nore...@ietf.org> Date: Monday, October 18, 2021 at 2:32 PM To: The IESG <i...@ietf.org> Cc: draft-ietf-bess-evpn-optimized...@ietf.org <draft-ietf-bess-evpn-optimized...@ietf.org>, bess-cha...@ietf.org <bess-cha...@ietf.org>, bess@ietf.org <bess@ietf.org>, Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com>, Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com> Subject: Roman Danyliw's No Objection on draft-ietf-bess-evpn-optimized-ir-09: (with COMMENT) Roman Danyliw has entered the following ballot position for draft-ietf-bess-evpn-optimized-ir-09: 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/blog/handling-iesg-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-evpn-optimized-ir/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Derek Atkins for the SECDIR review. ** Section 10. The following sentence doesn’t parse for me. Can the guidance on avoiding loops and the AR-REPLICATOR please be clarified. An implementation following the procedures in this document should not create BM loops, since the AR-REPLICATOR will always forward the BM traffic using the correct tunnel IP Destination Address that indicates the remote nodes how to forward the traffic. [jorge] I replaced the paragraph with the following text, please let me know if it helps clarify. Note it is a warning for the implementor, but it is not a strictly necessary text if it does not help. Let me know please. This document introduces the ability for the AR-REPLICATOR to forward traffic received on an overlay tunnel to another overlay tunnel. The reader may interpret that this introduces the risk of BM loops. That is, an AR-LEAF receiving a BM encapsulated packet that the AR-LEAF originated in the first place, due to one or two AR-REPLICATORs "looping" the BM traffic back to the AR-LEAF. The procedures in this document prevent these BM loops, since the AR-REPLICATOR will always forward the BM traffic using the correct tunnel IP Destination Address that indicates the remote nodes how to forward the traffic. This is true in both, the Non-Selective and Selective modes defined in this document. However, a wrong implementation of the procedures in this document may lead to those BM loops. ** Section 10. Editorial? OLD The forwarding of Broadcast and Multicast (BM) traffic is modified though, and BM traffic from … NEW The forwarding of Broadcast and Multicast (BM) traffic is modified; and BM traffic from ... [jorge] done, thx ** Section 10. Typo. s/existance/existence/ ** Editorial. Multiple places. Typo likely to rendering. s/section Section X.X/Section X.X/ [jorge] both fixed in revision 10, thx
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
