Re: [bess] EVPN FECs in LSP Ping

Donald Eastlake <d3e3e3@gmail.com> Sun, 23 September 2018 19:34 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 48E9A130E3B; Sun, 23 Sep 2018 12:34:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 EddwdKzj5Y6P; Sun, 23 Sep 2018 12:34:22 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 9827D126CB6; Sun, 23 Sep 2018 12:34:22 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id v14-v6so16089841iob.4; Sun, 23 Sep 2018 12:34:22 -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:content-transfer-encoding; bh=N4RtDlEq9J8zltGJLA4zYibunninGg/P53vcvXQPlBw=; b=CfZ+oRmtYAgXVANEl6Zht1rz32sfP8YyHriLOezYtoccaW4OcriIY0ycZ6C8H5dHiH zbjewYJviFq1znCGUExAWGGhRTb7jG3AltwZgcN1gdIMiiWSaDiK2OR298nVwW81DHUt yf8AmFaKHmFy4jIQFV+O8jNREISIksiqtCrb97izDB6hZAwbfS/7M8exNE4sRxfkEHFs uu6tsJ4kKfOQA2X/qyL7tEmV7R0KDy9ncM8u9Pda/TsM4wOYGv/wugcH2bCaM6gK7zzU GcdXsiSTqwTfwlSXPCTXuAO5MnnztOKOSGDH1PWoZV+gM8m4fXDnSvWiaGznHDSyXvEj oFdQ==
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:content-transfer-encoding; bh=N4RtDlEq9J8zltGJLA4zYibunninGg/P53vcvXQPlBw=; b=g9AFEiEqTaqMPTf0LgXLITxLKD5iaMp3bEJaLCHrDDvldwLSueng79PP5ftS78emkK foO8G5FXm9jX0rwkFE0h4MKazkWSTpdcacdFSiiWeDLGzY8KkjyyYQ6iOanGNSIrEHhw dkIfNV6GO5s779fZUtr87muvCezkb1LjY9V+hLDKAExqA4uWZ0SD+nAEu8ujnpAwJfjS yyWKI3HxBIvCOM54EQQGOqsNd/Z4gFvlMb1AJtQACztpSOJ0L29X45uszIM8thQHoiM1 GfLpdpa3zTz+GkJOdlwT/zkDHh0Ya9t5UC8TMT8YqjIoLd0HWghuTU6kDiOCPob6jE3C b67g==
X-Gm-Message-State: ABuFfoitr6bWD5XaJvc6LkAy9PYvuFtRJPxyDu4dl6WaKSl0Mx3GDSYf Q444W3OiV3JLpXdzAgcjKV5xm2cz7hz+sTTHyAE=
X-Google-Smtp-Source: ACcGV62PASqVw81kwYeQGus9B2RKlVI27jg3KofhWMYTApkfeUJgkGH06rnUYHIDs+aqqWLQnUfbt+M7WD4j22eevUk=
X-Received: by 2002:a6b:ac45:: with SMTP id v66-v6mr5950865ioe.66.1537731261770; Sun, 23 Sep 2018 12:34:21 -0700 (PDT)
MIME-Version: 1.0
References: <DB5PR0301MB1909275472D15F5A67E9E35B9D010@DB5PR0301MB1909.eurprd03.prod.outlook.com> <CAF4+nEHHNjvKdRYhXV6tVTPi=5vAYq5=ozuSeXK6ER5vYFJMSg@mail.gmail.com> <DB5PR0301MB19098730D14E61E72654C0099D120@DB5PR0301MB1909.eurprd03.prod.outlook.com>
In-Reply-To: <DB5PR0301MB19098730D14E61E72654C0099D120@DB5PR0301MB1909.eurprd03.prod.outlook.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Sun, 23 Sep 2018 15:34:06 -0400
Message-ID: <CAF4+nEGipCbKnmHREvknyx-hUFkHBTUMguZDGc77=3EMirLOtA@mail.gmail.com>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Cc: draft-salam-bess-evpn-oam-req-frmwk@ietf.org, bess@ietf.org, Michael.Gorokhovsky@ecitele.com, Ron.Sdayoor@ecitele.com, Rotem Cohen <Rotem.Cohen@ecitele.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/FuUbwp5LIiQwvlcTq7N1J-tyxIE>
Subject: Re: [bess] EVPN FECs in LSP Ping
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: Sun, 23 Sep 2018 19:34:24 -0000

Hi Sasha,

On Fri, Sep 21, 2018 at 1:02 PM Alexander Vainshtein
<Alexander.Vainshtein@ecitele.com> wrote:
>
> Donald,
> Lots of thanks for your response.
>
> I would like to clarify my question regarding learning of the MAC address of the customer MEP.
>
> I fully agree that this address will be locally learned by the PE to whic the relevant customer site is attached.
>
> But will this address advertised to remote PEs?
>
> My reading of 7432 is that in most cases PEs advertise MAC addresses that have been locally learned from some CP protocol; 7432 specifically mentions ARP/NDP and DHCP/DHCPv6.
>
> I think that in order to learn and advertise MAC addresses of customer MEPs, the PE should trap or snoop Ethernet Service OAM frames (trap is required for LTM frames if MIP us intanciated in the PE).
>
> Does this make sense to you?

I would agree that a PE has to advertise the MAC addresses it learns
from the local reception Ethernet Service OAM frames if it wants to
support that service and it would be reasonable to mention this in the
EVPN OAM framework document. RFC 7432 was not considering OAM.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e3e3@gmail.com

> Regards
>
> Thumb typed by Sasha Vainshtein
>
> From: Donald Eastlake
> Sent: Monday, September 17, 01:43
> Subject: Re: EVPN FECs in LSP Ping
> To: Alexander Vainshtein
> Cc: draft-salam-bess-evpn-oam-req-frmwk@ietf.org, bess@ietf.org, Michael Gorokhovsky, Ron Sdayoor, Rotem Cohen
>
> Hi Sasha, Thanks for your questions. See below. On Thu, Sep 6, 2018 at 9:58 AM Alexander Vainshtein wrote: > > Dear authors of the EVPN OAM requirements and Framework draft, > > I have looked up the draft, and it looks to me as a good starting > point for work on EVPN OAM. Thanks. > I would like to clarify two points with regard to the draft: > > 1. In order to pass unicast EAOM frames (LBM/LBR and LTR), the > local MAC-VRF must learn the MAC address of the customer MEP and > advertise it to remote PEs as a MAC/IP Advertisement route. Should > this be considered as a special case of learning from the control > plane (in addition to ARP/NDP/DHCP/DHCPv6 that are mentioned in RFC > 7432)? Yes, the MAC address of the customer MEP needs to be learned but Section 9.1 of RFC 7432 includes the following text, which seems adequate to me: The PEs in a particular EVPN instance MUST support local data-plane learning using standard IEEE Ethernet learning procedures. > 2. The draft seems to propose extension of LSP Ping to test/verify > connectivity to the FECs advertised as NRLI of EVPN routes. I have > checked the IANA Registry, and no values for these FECs have been > allocated yet. Do you plan any specific work on this? LSP Ping is one mechanism indirectly referenced in Section 2.4 of the draft via the reference to RFC 6425 but there are others. Since OAM messages need to follow the same path as data, as far as practical, it seem to me there should not be any FECs allocated for OAM beyond those already needed for data. Probably wording in the draft related to FECs should be checked/adjusted. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com