Skip to main content

Early Review of draft-ietf-bess-pbb-evpn-isid-cmacflush-04
review-ietf-bess-pbb-evpn-isid-cmacflush-04-rtgdir-early-white-2022-01-27-00

Request Review of draft-ietf-bess-pbb-evpn-isid-cmacflush
Requested revision No specific revision (document currently at 09)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2021-09-30
Requested 2021-08-27
Requested by Matthew Bocci
Authors Jorge Rabadan , Senthil Sathappan , Kiran Nagaraj , Masahiro Miyake , Taku Matsuda
I-D last updated 2022-01-27
Completed reviews Secdir Last Call review of -08 by Klaas Wierenga (diff)
Genart Last Call review of -07 by Joel M. Halpern (diff)
Intdir Telechat review of -08 by Pascal Thubert (diff)
Rtgdir Early review of -04 by Russ White (diff)
Comments
The document recently went through WG last call in BESS. The chairs would really appreciate broader review of the document. Thanks!
Assignment Reviewer Russ White
State Completed
Request Early review on draft-ietf-bess-pbb-evpn-isid-cmacflush by Routing Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/rtg-dir/Ax5lPXrc9IAQjO90LeSrTJ83hqQ
Reviewed revision 04 (document currently at 09)
Result Has nits
Completed 2021-10-22
review-ietf-bess-pbb-evpn-isid-cmacflush-04-rtgdir-early-white-2022-01-27-00
Hello,

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Document: draft-ietf-bess-pbb-evpn-isid-cmacflush
Reviewer: Russ White
Review Date: 22 October 2021
Intended Status: Standards Track

==
Summary:

This document is basically ready for publication but has nits that should be
considered prior to publication. Overall, the document is readable--the
labeling and layout of the diagrams can be confusing, however (see notes below
on figure 1). The flow of the document is fine, and the solution description
seems to be sufficient for a reader with knowledge of PBB and eVPN to
understand what is being done to resolve the problem.

Major Issues:

None.

Minor Issues:

Based on the description given for figure 1, it seems that ISID1 is a single
device connected once to CE1, once to CE2, and once to CE3. In turn, CE3
apparently has two connections into the PBB-eVPN network. If this is all
correct, then I find the diagram confusing.

ISID1 appears to be a _label_ for the three CE devices, rather than connected
to them ... or are the three CE's actually the same device as ISID1? Or is
ISID1 a different device, connected (according to the labels) to an MPLS Ag
network and a G.8032 access ring? This configuration seems a little odd to me.

The connectivity shown between PE3, PE4, and CE3 is not clear. Are there two
links from PE3 and CE3, or one? If there is one, why are there two different
sets of lines, one of which is labeled "vES null," and the other labeled with
the state of the connection (act or stb)? What is the significance of this
particular connection layout?

The terms "act" and "stb" are not used anywhere in the text; in theory,
somewhere above when the word "standby" is used, it would have a note saying
"denoted as stb in the diagram below," or something similar. Otherwise, the
reader is left trying to understand what the labels "act" and "stb" mean.

What is the significance of the "MPLS Ag Network" in the lower right corner of
the diagram? If this is supposed to label the part of the network which is not
PBB-eVPN, then shouldn't it be below the diagram, similar to how the label for
the PBB-eVPN network is above the network? Is there any reason that it matters
for this use case that the vES null attached PEs or devices are part of some
other MPLS network? Could they just be part of a plain IP network? It seems to
me, reading the text, that the impact would be the same even if these devices
were part of a plain IP network?

I see, on the right side, the label "MPLS Ag," and (possibly) a corresponding
label on the left side saying "G.8032 Access Ring." It seems a bit odd that the
label for the PBB-eVPN network is above the diagram, but these two labels,
which appear to refer to other parts of the network appear to be incorprated
into the diagram itself (?). Why this difference? If these are denoting
different parts of the network, it would help the reader understand the diagram
better if they were all in the same location in the diagram (?).

Are the kinds of network outside the PBB-eVPN network important? Does it matter
if one of the two connections from ISID1 (I'm assuming there's a single device
here) is through an MPLS network of some other type, and its other connections
is through an access ring? Would it make any difference if the entire diagram
were simplified to show a single device connected via plain Ethernet in three
different places, one of which has redudant links into the PBB-eVPN network? I
understand there is underlying resilience in these different technologies, but
I'm not certain how that impacts the operation of the mechanism described in
the draft.

Nits:

4b is missing a "T."

==

:-) /r