Thanks, not sure if something needs to be done. I see tracker still shows that it has issue.
From: Mach Chen <mach.c...@huawei.com> Date: Thursday, October 26, 2023 at 7:25 PM To: Mankamana Mishra (mankamis) <manka...@cisco.com>, rtg-...@ietf.org <rtg-...@ietf.org> Cc: bess@ietf.org <bess@ietf.org>, draft-ietf-bess-evpn-ac-aware-bundling....@ietf.org <draft-ietf-bess-evpn-ac-aware-bundling....@ietf.org> Subject: RE: Rtgdir early review of draft-ietf-bess-evpn-ac-aware-bundling-01 Hi Mankamana, I just checked the latest version, it addressed my comments. Thanks, Mach From: Mankamana Mishra (mankamis) <manka...@cisco.com> Sent: Friday, September 15, 2023 11:18 PM To: Mach Chen <mach.c...@huawei.com>; rtg-...@ietf.org Cc: bess@ietf.org; draft-ietf-bess-evpn-ac-aware-bundling....@ietf.org Subject: Re: Rtgdir early review of draft-ietf-bess-evpn-ac-aware-bundling-01 Had hit premature send button, all the review comments have been addressed. From: Mankamana Mishra (mankamis) <manka...@cisco.com<mailto:manka...@cisco.com>> Date: Thursday, September 14, 2023 at 3:32 PM To: Mach Chen <mach.c...@huawei.com<mailto:mach.c...@huawei.com>>, rtg-...@ietf.org<mailto:rtg-...@ietf.org> <rtg-...@ietf.org<mailto:rtg-...@ietf.org>> Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, draft-ietf-bess-evpn-ac-aware-bundling....@ietf.org<mailto:draft-ietf-bess-evpn-ac-aware-bundling....@ietf.org> <draft-ietf-bess-evpn-ac-aware-bundling....@ietf.org<mailto:draft-ietf-bess-evpn-ac-aware-bundling....@ietf.org>> Subject: [SUSPICIOUS] Re: Rtgdir early review of draft-ietf-bess-evpn-ac-aware-bundling-01 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 <nore...@ietf.org<mailto:nore...@ietf.org>> Date: Thursday, July 13, 2023 at 2:00 AM To: rtg-...@ietf.org<mailto:rtg-...@ietf.org> <rtg-...@ietf.org<mailto:rtg-...@ietf.org>> Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, draft-ietf-bess-evpn-ac-aware-bundling....@ietf.org<mailto:draft-ietf-bess-evpn-ac-aware-bundling....@ietf.org> <draft-ietf-bess-evpn-ac-aware-bundling....@ietf.org<mailto:draft-ietf-bess-evpn-ac-aware-bundling....@ietf.org>> 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.
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
