Re: [bess] Roman Danyliw's No Objection on draft-ietf-bess-evpn-optimized-ir-09: (with COMMENT)

[Roman Danyliw <[e-mail]>]

Hi Jorge!

Looks fine to me.  Thanks for the edits.

Roman

From: Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]>
Sent: Monday, November 8, 2021 10:19 AM
To: Roman Danyliw <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; Bocci, Matthew (Nokia - GB) <[e-mail]>
Subject: Re: Roman Danyliw's No Objection on draft-ietf-bess-evpn-optimized-ir-09: (with COMMENT)

Hi Roman,

Thanks for the review.
Please see the resolution of your comments in-line with [jorge].

Thx
Jorge

From: Roman Danyliw via Datatracker <[e-mail]<mailto:[e-mail]>>
Date: Monday, October 18, 2021 at 2:32 PM
To: The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Bocci, Matthew (Nokia - GB) <[e-mail]<mailto:[e-mail]>>, Bocci, Matthew (Nokia - GB) <[e-mail]<mailto:[e-mail]>>
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