Sorry for delay in reply. Have made the update in draft and below are the changes in 2nd version of draft getting uploaded today. Please let me know if this covers your comments.
From: Mach Chen via Datatracker <[email protected]> Date: Thursday, July 13, 2023 at 2:00 AM To: [email protected] <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Rtgdir early review of draft-ietf-bess-evpn-ac-aware-bundling-01 Reviewer: Mach Chen Review result: Has Issues Summary: I have some minor concerns about this document that I think should be resolved before it is submitted to the IESG. Here are my comments: 1. There are many different uses of multi-homing or the like in the draft, e.g., "multi-homing", "multihoming", "multihome", "multi-homed", "multihomed"; "non multihoming" vs "non-multihome", etc. The author needs to check through the document to make the usage consistent. There is a similar issue to "Broadcast Domain" vs "broadcast domain", "all-active" vs "all active", "Attachment Circuit" vs "attachment-circuit",etc. Mankamana : Multihoming – aligned with RFC7432 and draft 7432bis Broadcast domain changed to consistently - broadcast domain All form of all active changed to align with RFC 7432 – All-Active All form of attachment circuit changed to - attachment circuit 2. For unwell-known acronyms, it's better to expand them upon their first use. This helps readers understand the context and prevents confusion. Mankamana : Expanded some of terms (aligned with RFC 7432 abstract). Did not expand some of well known terms vlan , mpls . please let me know if we think it need to be expanded too 3. There is a concept: multi-homed EVPN peers, but lack of definitions, some places in the draft also use "multi-homed PEs", "multihomed peers", "multihome peers", "peering PE", etc. I guess that they are the same meaning and should be used consistently through the document. Mankamana : Alighned with RFC 7432 where it uses term PE all of the places. There is peer used where it is appropriate 4. Section 1.1 s/BD-1 has.../In Figure 1, BD-1 has... s/belongs too/belongs to Done 5. Section 1.2 s/forearded to proper AC/forwarded to the proper AC Done 6. Section 3 1) I assume that the "service interface" is the new defined service interface in this document, am I right? If so, a "new" should be added before the "service interface", just as the requirements 5, 6 do. 2) Requirement 1 seems self-contridiction, multiple VLAN configured on an attachement-circuit, but each VLAN is represented by a different AC, how to understand this? Rewording or some clarification needed here. 3) Not sure the intention/meaning of requirement 2, clarification needed here. 4) Requirement 3 has been stated in the introduction section, IMHO, the entire section can be removed and put some of the requirement to other places (e.g., the introduction seciton, the place where the New service interface is defined. Mankamana : Yes its new service interface. Added the new term. Thanks for catching the issue with first requirement , added statement that each of VLAN would be represented by AC ID . removed the 2nd requirement. I think this section helps to clearly get the summary of what this draft is presenting. 7. Section 4.1.1.1 s/PEs where.../At those PEs where... s/An attach Attachment.../An Attachment... s/MAC/IP route.../The MAC/IP Advertisement route s/to EVPN RT-2/to EVPN Route Type 2 (RT-2) Done 8. Section 4.1.1.2 s/to attach remote MAC address to appropriate AC/to associate the remote MAC address to the appropriate AC Done 9. Section 4.1.2.1 Should the "local multihomed AC" be "local multihomed PE"? s/must/MUST, same usage at other places, it needs to check through the whole document. Done 10. Sectionn 4.1.2.2 "route MUST be programmed to correct subnet", what's the meanning of this sentence? Rewording/clarification needed here. Next few statement provides detail about it where subnet is nothing but the VLAN where the join came . reading next few lines along with this should clarify. If its still not clear please let me know. . 11 Section 5 The current description looks like a general requirement, but does not define how to achieve this. IMHO, it'e better to move this section Section 6, as sub-section, and define the details on to detect this error with the BGP protocol processing. I think this would be relevant for for implementation. Next sections are mostly talking about BGP encoding errors but this section is specific about VLAN config issue where BGP route does not have problem but both peer are not configured with same set of VLAN. 12. Section 6.1 s/A new EVPN BGP Extended Community/A new BGP Extended Community s/...called Attachment Circuit ID/...called Attachment Circuit ID Extended Community Given the Sub-Type is allocated by the INNA, the "TBD" in the text and Figure should be update to specific value. Updated 13. There are 6 authors listed in the front page, according to the IESG/IETF policy, no more than 5 authors should be listed on the front page unless there is reasonable cause. Will discuss with authors and take care of it .
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
