Subject: [bess] Martin Duke's No Objection on draft-ietf-bess-evpn-oam-req-frmwk-06: (with COMMENT)

From: Martin Duke via Datatracker <[email-masked]>
Date: Fri, 26 Mar 2021 09:23:28 -0700

Martin Duke has entered the following ballot position for
draft-ietf-bess-evpn-oam-req-frmwk-06: 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:
----------------------------------------------------------------------

Thanks to David Black for the tsvart review, and for the authors addressing his
comments.

Sec 2.2 It would help to define "up" and "down" connections.

Sec 3.2.1 & 3.2.2. I am not sure of the extent which IPPM metrics and methods
can apply to these layers. But there are some references that can guide loss,
delay, and jitter measurements:

Loss: RFC 7680, RFC 6673

Delay: RFC 7679, RFC 2681

Jitter: RFC 3393

I encourage the authors to peruse IPPM's published RFCs on datatracker to see
if other documents would be similarly useful.

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 27 Mar 2021 15:47:13 -0400

Hi Martin,

On Fri, Mar 26, 2021 at 12:23 PM Martin Duke via Datatracker
<[email-masked]> wrote:
> ...
> Thanks to David Black for the tsvart review, and for the authors
> addressing his comments.
>

The -06 version of the draft includes the following text which sort of
defines "up" and "down" but I'm not sure it does so clearly or even
completely accurately in this case :-(

   The EVPN PE MUST support MIP functions in the applicable service OAM
   protocol, for example Ethernet CFM. The EVPN PE SHOULD support MEP
   functions in the applicable service OAM protocol. This includes both
   Up and Down MEP functions. As shown in Figure 3, the MIP and MEP
   functions being referred to are logically located within the CE
   facing port of a PE. Down MEP functions are towards the CE. Up MEP
   functions are towards the PE forwarding mechanism. CFM between the PE
   Up MEPs is a type of EVPN Network OAM while CFM between the CEs or
   from a PE to its local CE or to the remote CE is Service OAM.

So how about the following replacement wording:

   The EVPN PE MUST support MIP functions in the applicable service OAM
   protocol, for example Ethernet CFM. The EVPN PE SHOULD support MEP
   functions in the applicable service OAM protocol. This includes both
   Up and Down MEP functions.

   As shown in Figure 3, the MIP and MEP functions being referred to
   are logically located within the device's port operating at the
   customer level. (There could be MEPs/MIPs within PE ports facing
   the provider network but they would not be relevant to EVPN Service
   OAM as the traffic passing through them will be
   encapsulated/tunneled so any customer level OAM messages will just
   be treated as data.)  Down MEP functions are away from the device
   while up MEP functions are towards the device (towards the PE
   forwarding mechanism in the case of a PE). OAM messages between the
   PE Up MEPs are a type of EVPN Network OAM while such messages
   between the CEs or from a PE to its local CE or to the remote CE is
   Service OAM.

and perhaps adding entries for "Down MEP" and "Up MEP" in the
Terminology section. Also the following adjusted figure 3 might show
more clearly that the MEPs/MIPs are part of the CEs/PEs:

   +-------+   +----------------+       +----------------+   +-------+
   |+-----+|   |+--------------+|       |+--------------+|   |+-----+|
   ||  CE ||   ||     PE1      ||  ...  ||      PE2     ||   || CE  ||
   |+--+--+|   |+---+--------+-+|       |+-+--------+---+|   |+--+--+|
   |   |   |   |    |        |  |       |  |        |    |   |   |   |
   |+--+--+|   |+---+-----+  .  |       |  .  +-----+---+|   |+--+--+|
   || MEP ||   ||   | Up^ |  .  |  ...  |  .  |Up^  |   ||   || MEP ||
   ||DownV||   ||MIP|MEP  |  .  |       |  .  |MEP  |MIP||   ||downV||
   |+--+--+|   ||   |DownV|  .  |       |  .  |DownV|   ||   |+--+--+|
   |   |   |   |+---+-----+  |  |       |  |  +-----+---+|   |   |   |
   +---|---+   +----|--------|--+       +--|--------|----+   +---|---+
       |            |        |             |        |            |
       +------------+        +---  ...  ---+        +------------+

> if other documents would be similarly useful.

Thanks for the references. I do not see any problem in adding these
references for delay and jitter to Section 3.2.2 of the draft and the
references for loss to Section 3.2.1 of the draft.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

---

From: Martin Duke <[email-masked]>
Date: Sat, 27 Mar 2021 12:54:12 -0700

I straight up missed that definition. So use whichever text you prefer.

Thanks for adding the references.

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 27 Mar 2021 17:49:27 -0400

I think my suggested revision was a significant improvement so I've
gone ahead with these minor changes and postes a -07 version.

Thanks,
Donald