Hello Jorge, Thanks for your reply, the fix, and the explanations. All is good for me and I think the I-D is in better shape.
Regards -éric From: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> Date: Sunday, 18 August 2024 at 03:17 To: Eric Vyncke (evyncke) <evyn...@cisco.com>, The IESG <i...@ietf.org> Cc: draft-ietf-bess-evpn-mh-split-hori...@ietf.org <draft-ietf-bess-evpn-mh-split-hori...@ietf.org>, bess-cha...@ietf.org <bess-cha...@ietf.org>, bess@ietf.org <bess@ietf.org>, slitkows.i...@gmail.com <slitkows.i...@gmail.com>, Mankamana Mishra (mankamis) <manka...@cisco.com>, zzh...@juniper.net <zzh...@juniper.net>, Matthew Bocci (Nokia) <matthew.bo...@nokia.com> Subject: Re: Éric Vyncke's No Objection on draft-ietf-bess-evpn-mh-split-horizon-10: (with COMMENT) Hi Éric, We appreciate your thorough review. Your comments are addressed in version 11. Please see in-line with [jorge]. Thank you! Jorge From: Éric Vyncke via Datatracker <nore...@ietf.org> Date: Tuesday, August 6, 2024 at 7:33 AM To: The IESG <i...@ietf.org> Cc: draft-ietf-bess-evpn-mh-split-hori...@ietf.org <draft-ietf-bess-evpn-mh-split-hori...@ietf.org>, bess-cha...@ietf.org <bess-cha...@ietf.org>, bess@ietf.org <bess@ietf.org>, slitkows.i...@gmail.com <slitkows.i...@gmail.com>, manka...@cisco.com <manka...@cisco.com>, zzh...@juniper.net <zzh...@juniper.net>, Matthew Bocci (Nokia) <matthew.bo...@nokia.com>, zzh...@juniper.net <zzh...@juniper.net> Subject: Éric Vyncke's No Objection on draft-ietf-bess-evpn-mh-split-horizon-10: (with COMMENT) 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. Éric Vyncke has entered the following ballot position for draft-ietf-bess-evpn-mh-split-horizon-10: 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-positions%2F&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C9e59d462f46b45ea465b08dcb624c8bf%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638585516324369241%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2FnzSx%2FEKV0ehv65IwKvOTSh294V2jjf%2F79UvADaej0c%3D&reserved=0<https://www.ietf.org/about/groups/iesg/statements/handling-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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-bess-evpn-mh-split-horizon%2F&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C9e59d462f46b45ea465b08dcb624c8bf%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638585516324380377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=vyM4nECn5SeYwMdGq2rtOawV6oFIehNo2uUWPoToOu8%3D&reserved=0<https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-mh-split-horizon/> ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-bess-evpn-mh-split-horizon-10 Thank you for the work put into this document. I found the writing quite convoluted and not easy to follow, especially about what is modified from RFC 7432 and others. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Jeff Zhang for the shepherd's write-up including the WG consensus and the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Relevance to BESS ? Wondering whether this work fits well within BESS charter; some EVPN (e.g., VXLAN) are deployed without using BGP and still require split-horizon (if not mistaken). Strongly suggest to add BGP in the title of this document (and abstract) to make it clear that this is about BGP and not EVPN. [jorge] As defined in RFC7432, EVPN is always BGP-based, i.e. it requires the exchange of BGP NLRIs to implement all the procedures in the RFC. We added BGP in the title. ## Abstract `to select the appropriate Split Horizon procedure` does it mean that the other procedure is *not* appropriate or simply *less* appropriate ? [jorge] not really, it means that the other procedure may be appropriate too, but the operator prefers one over the other for any reason that is out of scope. For example, an operator may prefer “local bias” because always forwards the traffic locally to other multihomed attachment circuits irrespective of who the designated forwarder is, as opposed to send it to the peer PE. I changed the text to the following, hopefully it improves the readability: “to select the Split Horizon procedure that meets their specific requirements” ## Section 1 Suggest to clearly define "split horizon" rather than simply burry it in `Split Horizon procedures employed to prevent looped frames`. [jorge] We added the following, hopefully it helps: “Split Horizon, in this document, follows the definition in RFC7432. Split Horizon refers to the EVPN multihoming procedure that prevents a PE from sending a frame back to a multihomed Customer Edge (CE) when that CE originated the frame in the first place.” ## Section 1.1 s/link-local broadcasts/link-layer broadcasts/ ? what about other unknown/multicast traffic ? [jorge] I replaced it with “broadcast, unknown and multicast traffic” Several acronyms (e.g., "BUM") keep being expanded in the following sections. [jorge] fixed now, thanks ## Section 2.1 Just wondering where the RED bits are defined (they seems to overwrite the single-active bit of section 2), please add a reference to RFC 7432. [jorge] added a reference to section 5, which is by the way changed and where RFC7432 is referenced too. Also, is there a reason why the SHT bits are not adjacent to the RED ones ? [jorge] at the time there were some other documents taking some bits from the flags field, and we wanted to be safe to avoid clashing. # NITS (non-blocking / cosmetic) ## Section 1.1 s/ethernet/Ethernet/ (possibly in other places) Be consistent "Segment *R*outing" vs. "Segment *r*outing" ;-) ## Section 2 Please add markers for 10, 20, ... on figure 1 [jorge] fixed, thx
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
