[bess] Robert Wilton's No Objection on draft-ietf-bess-evpn-oam-req-frmwk-08: (with COMMENT)

Robert Wilton via Datatracker <noreply@ietf.org> Thu, 08 April 2021 13:36 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: bess@ietf.org
Delivered-To: bess@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 578C23A17EB; Thu, 8 Apr 2021 06:36:07 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Wilton via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-bess-evpn-oam-req-frmwk@ietf.org, bess-chairs@ietf.org, bess@ietf.org, Matthew Bocci <matthew.bocci@nokia.com>, matthew.bocci@nokia.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.27.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Robert Wilton <rwilton@cisco.com>
Message-ID: <161788896681.26574.4226145616532562392@ietfa.amsl.com>
Date: Thu, 08 Apr 2021 06:36:07 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/4iVsOuyWFflG85PYntwUVoR-QS8>
Subject: [bess] Robert Wilton's No Objection on draft-ietf-bess-evpn-oam-req-frmwk-08: (with COMMENT)
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 08 Apr 2021 13:36:07 -0000

Robert Wilton has entered the following ballot position for
draft-ietf-bess-evpn-oam-req-frmwk-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-oam-req-frmwk/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

Thanks for this document.

It's a bit unclear to me whether the descriptions/definitions of MIP/MEP/MA/MD
are coming from CFM or RFC 6136.  Section 1.1 suggests that they are coming
from CFM (but without a normative reference to 802.1Q), but the terminology
implies that they are being taken from RFC 6136.
 Certainly, there seem to be places in this document where more meaning of
 these terms seems to be expected than what is provided in the terminology
 section.   Section 2.6 refers to CCMs, but I think that a reader would only
 understand what these are if they have read CFM.  Hence, I think that this
 document would probably benefit from having a normative reference to 802.1Q
 rather than informative.

Minor comments:

    2.1 OAM Layering

    "and shows which devices have visibility into what OAM layer(s)."

Perhaps indicate by the 'o' symbol. Otherwise the fact that the Link OAM is the
end point of the physical links, whereas the other OAM endpoints are may cause
confusion.

Figure 2:
 - Would it be helpful to move the 'o' marks to the end of the PE devices, to
 line up with the Link OAM end points?

 - Is "Service CFM" the right term here?  Does this mean "Service OAM - CFM"?

 - Probably helpful to add an informative reference to 802.3 Link OAM, which is
 in figure 2.

2.2 EVPN Service OAM

- I'm not sure how clear "towards the device" is when the point is already
within the device.

- The up and down arrows for the MEPS ("^" and "V") seem to potentially make
Figure 3 more confusing.  Also "down" should be changed to "Down" in the last
CE.

Nits:

I'm not sure why the PE nodes are numbered by CE nodes are not.

Regards,
Rob