[bess] RtgDir Last Call review: draft-ietf-bess-pbb-evpn-isid-cmacflush

opens@riw.us Fri, 22 October 2021 20:05 UTC

Return-Path: <opens@riw.us>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 130263A0E7A; Fri, 22 Oct 2021 13:05:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9Sy_W2ZymJb; Fri, 22 Oct 2021 13:05:42 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B6003A0E7C; Fri, 22 Oct 2021 13:05:37 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 24A6E5C00E6; Fri, 22 Oct 2021 16:05:37 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 22 Oct 2021 16:05:37 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=pMaBkJ ppfBocrlOstM63pWCx3FstLHJShq7NljZFrrY=; b=lSLf4qGPhCyiegBafb+Ymu ayKi+qdZf5HDh8YnsDoLfbC03dntG7VbgApCVNGQJojh8Vq1KuZLScjt42acPRn8 trMb5QHe27bFlA6kBjf04dwOAe3WDdXK4WmC+PPSOM7qgEUbFRmFCqrQ8zLDT/Z5 84d6jTzI/9PBvU6L5evar5G0E4FqdXjAueFQkbukk+P7+2uxNzOuEx6S+BL/qrDK +OUxp3iyyLP83vU+P4Cs8SzpcDdv+5T4Po7ZCyAaM1ahky36LotQXuRLctPfzav+ dFCfOqb5Gu9/o7c67f5GtMawkSAItsDIk4y5zndhjU2+NPIcjeFe1BeFW7R+7bkg ==
X-ME-Sender: <xms:kRlzYWQdIZuBkO5QwgJ0csk6LmmdVsVpQ86p-sF_YDRTuC63GIvFKA> <xme:kRlzYbx3p-UnJI4_7FpqZIUhvfHh4LM7lxDOvB7u6vD4sF6Bbt7G5HFpNIjt67z3E SOsfXYPiF4dsy5wBQ>
X-ME-Received: <xmr:kRlzYT07kZ6rvIB3wkXM-j8V8Q0OSiVS_p3DRE9bMNz5JpNyXBpPbLTAKAjR-Fp8KrBAGmCQqOWCb-Cu4FzJC56ohedaFY_0PpmvGBT93xgyDyQHVGU>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddvkedgudegvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufffkfggtgfgofhtsehtqh hgtddvtdejnecuhfhrohhmpeeoohhpvghnshesrhhifidruhhsqeenucggtffrrghtthgv rhhnpedujedttdekheevhfdvkefgkeeuheeutdegkeefheevgeevudekudeludelgeejff enucffohhmrghinhepihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepohhpvghnshesrhhifidruhhs
X-ME-Proxy: <xmx:kRlzYSBzLsY7RRNeQGlb7nwiaSmkEghFyJkrHOAq6Faq4JcxDMZhjA> <xmx:kRlzYfiI-Tokx3e3yogFTr0KmsJELYD_PrCWcfk0AnFK4GBSwfA3Sg> <xmx:kRlzYeq91CJIKpMC0UOkuYL4NMAi3AYl_BZrusVOWW3DOPHm03l_Bw> <xmx:kRlzYSu93yazYHIwEEQeO_biykLd_v9gxrZjkDKBufDn6eXDGowmCg>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 22 Oct 2021 16:05:36 -0400 (EDT)
From: opens@riw.us
To: rtg-ads@ietf.org
Cc: rtg-dir@ietf.org, draft-ietf-bess-pbb-evpn-isid-cmacflush.all@ietf.org, bess@ietf.org, last-call@ietf.org
Date: Fri, 22 Oct 2021 16:05:36 -0400
Message-ID: <4b6c01d7c780$2dab6eb0$89024c10$@riw.us>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdfHgChA6AFGPCzJSnyjUeN3Xxg8Sg==
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/1207K4GM7FBfQ7uyzK6Z5yFhrpE>
Subject: [bess] RtgDir Last Call review: draft-ietf-bess-pbb-evpn-isid-cmacflush
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Oct 2021 20:05:51 -0000

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