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

Donald Eastlake <d3e3e3@gmail.com> Thu, 08 April 2021 04:12 UTC

Return-Path: <d3e3e3@gmail.com>
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 C44D53A0ACB; Wed, 7 Apr 2021 21:12:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.604
X-Spam-Level:
X-Spam-Status: No, score=-0.604 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 6eAzHXPTAD-R; Wed, 7 Apr 2021 21:12:53 -0700 (PDT)
Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D2F93A09F6; Wed, 7 Apr 2021 21:12:52 -0700 (PDT)
Received: by mail-il1-x133.google.com with SMTP id d2so624110ilm.10; Wed, 07 Apr 2021 21:12:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=elkK1/bPxsswD6Tr892lRnBdAp6C2TkFc7ozNyqtR1A=; b=Okd36PviKFPkzsXqF0oAA9LeVL1ykCVI1Eb2sk8q2lKfUUBs5S/erXNY3XpvrhnUsr Zoo1jQIx9KOrfhbzToEpx3wvIu2C1u6DT+T5EQjCF6x3Je/I72cw+R+4av72ZDg9kmgp QHOFwVIe+GnRJJY1LV3X97UOxeHBQjxN1SGWkNol88whvmqW+p9xyt+v/Oh4RKI+5cKk fv+hf3t9oDf+21wQRaCYJsqWEhmLopZOkfRZqB0xnx78MSVMnqtg1WVnIo/3CqNmhgQJ BA1YkKZX68LCHpu8JmjCKc6sdy7MUAEXDx1rm9HbkOeB/uj22VmHaRIc0xPugPrPcN7W zzJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=elkK1/bPxsswD6Tr892lRnBdAp6C2TkFc7ozNyqtR1A=; b=e57GsmRAXduni0ERNBDZrqjDQM0p1CWzM0V8zHs+6BgMJ+iFtnAevkGVCiuBJCMFNj ROtMFP0mW++QIgIv/m3IYDHxRsq5Hy1FVcr4RWo+a0RwKuTmgFc+Pybz7Soo2eDak+kJ 5KOD6nz7f4TkqL/vPHQDq7ehAFispMWC6+xHhgpvug/1TUZX6VysdlpUVWT77L1U5qVe OpBt2c075EP4zS411dqFO4nUHUSTR5T9curcBTDRDIpt6PHLhWEb4a+7r+wXpdyoQS+g VN7GR356J37D6i8E0/PW6D5mxNow2ys7pjwGzXRik9Nrghu/mgY8Y2+0RBjLEZbDo8pH 9QwQ==
X-Gm-Message-State: AOAM532iidSkKx23dbgPdkaTC7A1yHFn9veibCi8bd3u+7PzueHX6922 1qsbkhqkzluAbt8JvGItxnLHz/Fke1k4t9ueuMgxChs2du4=
X-Google-Smtp-Source: ABdhPJzzuWoAHnzeRV/kloBnPZLfcSmgeoTgOZxV9RV5VdfO/C8iMREDRG9qzL7JqkcqA5jP7ry141n697cLgFmm8to=
X-Received: by 2002:a05:6e02:12c9:: with SMTP id i9mr5431574ilm.276.1617855170782; Wed, 07 Apr 2021 21:12:50 -0700 (PDT)
MIME-Version: 1.0
References: <161783243454.23241.5762106088422783662@ietfa.amsl.com> <CAF4+nEFDWjTcRvjXihL1xOQhTEWe4sdjcAaoNQ+exnfRnQy7-A@mail.gmail.com> <B3EDB284-C75A-410E-84BF-C18B5741EDD8@juniper.net>
In-Reply-To: <B3EDB284-C75A-410E-84BF-C18B5741EDD8@juniper.net>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Thu, 08 Apr 2021 00:12:39 -0400
Message-ID: <CAF4+nEFKJLeqs7ULOev=LtmVb7e6SLOJDshfhv9_=NzCOizfeg@mail.gmail.com>
To: John Scudder <jgs@juniper.net>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-bess-evpn-oam-req-frmwk@ietf.org" <draft-ietf-bess-evpn-oam-req-frmwk@ietf.org>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, BESS <bess@ietf.org>, Matthew Bocci <matthew.bocci@nokia.com>
Content-Type: multipart/alternative; boundary="000000000000c0ab7605bf6e42de"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/MWMWbtjd28xri3WQp7qP-NeWJJ8>
Subject: Re: [bess] John Scudder'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
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: Thu, 08 Apr 2021 04:12:59 -0000

Hi John,

On Wed, Apr 7, 2021 at 10:02 PM John Scudder <jgs@juniper.net> wrote:
> Hi Donald,
>
> Thanks for your reply.
>
> On Apr 7, 2021, at 9:22 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:
>
> ...
>
> 2. Section 2.3:
>
>    EVPN Network OAM mechanisms MUST provide in-band monitoring
>    capabilities. As such, OAM messages MUST be encoded so that they
>    exhibit identical entropy characteristics to data traffic in order
>    that they share the same fate.
>
> It’s not obvious to me what you mean by “identical entropy
characteristics to
> data traffic”. Surely, different flows may have different entropy
> characteristics, so, *which* data traffic? Similarly, with which data
traffic
> are you saying the OAM messages must share fate?
>
>
><de> Well, it depends on what is meant by "characteristics". I believe the
><de>intent is to say that with a sufficient quantity of OAM messages, all
><de>paths used by actual data will be exercised.
>
>
> Your explanation (“all paths… will be exercised”) seems inconsistent with
§3.1.1.1:
>
>    - all paths. For MPLS/IP networks with ECMP, monitoring of all
>      unicast paths between MEPs (on non-adjacent nodes) may not be
>      possible, since the per-hop ECMP hashing behavior may yield
>      situations where it is impossible for a MEP to pick flow entropy
>      characteristics that result in exercising the exhaustive set of
>      ECMP paths. Monitoring of all ECMP paths between MEPs (on non-
>      adjacent nodes) is not a requirement for EVPN OAM.
>
> Even if the above somehow isn't the issue it appears to be, I think it’s
evident that the §2.3 text in question isn’t unambiguous enough to have a
MUST applied to it, I think this needs to be rectified in some way. I’m
going to switch my ballot to a DISCUSS until we’ve resolved this.
>
> (Now that I’m looking at the §2.3 text again, “identical” bugs me too,
since identity is a much stronger requirement than, say, similarity. But
since I suspect the text will be rewritten anyway it’s not worth dwelling
on.)

<de>Geez, here I put this text, which I inherited when I became pen holder
after draft-salam-l2vpn-evpn-oam-req-frmwk, in the best possible light and
you still object !  :-)

<de> OK, how about something more like:

EVPN Network OAM mechanisms MUST provide in-band monitoring capabilities.
OAM messages SHOULD be encoded so that they exhibit similar entropy
characteristics to data traffic in order maximize the fate sharing between
OAM and data.


<de> Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com

> Thanks,
>
> —John