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

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

Thanks for your comments. Working on changes based on your comments. Will be sending the diff soon and I think new version uploads would be allowed only towards IETF date.

Mankamana

From: Mach Chen via Datatracker <[e-mail]>
Date: Thursday, July 13, 2023 at 2:00 AM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[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.

2. For unwell-known acronyms, it's better to expand them upon their first use.
This helps readers understand the context and prevents confusion.

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.

4.
Section 1.1
s/BD-1 has.../In Figure 1, BD-1 has...
s/belongs too/belongs to

5.
Section 1.2
s/forearded to proper AC/forwarded to the proper AC

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.

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)

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

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.

10.
Sectionn 4.1.2.2
"route MUST be programmed to correct subnet", what's the meanning of this
sentence? Rewording/clarification needed here.

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.

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.

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.