Re: [RTG-DIR] Rtgdir early review of draft-ietf-bess-evpn-ac-aware-bundling-01

["Mankamana Mishra (mankamis)" <[e-mail]>]

Thanks, not sure if something needs to be done. I see tracker still shows that it has issue.

From: Mach Chen <[e-mail]>
Date: Thursday, October 26, 2023 at 7:25 PM
To: Mankamana Mishra (mankamis) <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
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) <[e-mail]>
Sent: Friday, September 15, 2023 11:18 PM
To: Mach Chen <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]
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) <[e-mail]<mailto:[e-mail]>>
Date: Thursday, September 14, 2023 at 3:32 PM
To: Mach Chen <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[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]>>
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 <[e-mail]<mailto:[e-mail]>>
Date: Thursday, July 13, 2023 at 2:00 AM
To: [e-mail]<mailto:[e-mail]> <[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]>>
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.