Re: [bess] A question regarding Single-Active ES redundancy mode and DF election in RFC 7432

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Tue, 04 September 2018 11:53 UTC

Return-Path: <Alexander.Vainshtein@ecitele.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 78E5A130E0D for <bess@ietfa.amsl.com>; Tue, 4 Sep 2018 04:53:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.789
X-Spam-Level:
X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.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 rl8MyHUIF6Qm for <bess@ietfa.amsl.com>; Tue, 4 Sep 2018 04:53:56 -0700 (PDT)
Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B26D3130DF4 for <bess@ietf.org>; Tue, 4 Sep 2018 04:53:55 -0700 (PDT)
Received: from [46.226.52.101] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-4.bemta.az-a.eu-west-1.aws.symcld.net id D0/D4-27733-2527E8B5; Tue, 04 Sep 2018 11:53:54 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDJsWRWlGSWpSXmKPExsViougQqxtY1Bd tcO2wnMWK4zOZLf79+cFs8e5sM4sDs8eU3xtZPXbOusvusWTJT6YA5ijWzLyk/IoE1oxH5+ML 3n1gqrhy06OB8c9rpi5GLg4WgUXMEjumvgJzhASmMEm86XvJDOE8YpRYfOs4SxcjJwebgK3Ep tV32boYOThEBAwkuo46gdQwCzQySTxseMAOUiMskCbx//B7VhBbRCBd4tD1ZijbTeL1ngNgNS wCKhI3Pt8Es3kFEiXeLN8HtWw2k8S8WzNYQRZwAi37uyYXpIZRQEzi+6k1TCA2s4C4xK0n88F sCQEBiSV7zjND2KISLx//Y4WoT5K4/3QhI0RcUWLGvTnsELasxKX53VDxg+wS52aJQNiGEsdX 7mcGWSsh4CtxdLoNhKksseVFLMhlEgKXGSVmf9oPNUZHYkn3W6gTCiSav/ezQRT1MEpcm7cRq khOYlXvQxaIxHZmib7XzVCHykic7Z3CCJG4zybxpL2NZQKj7iwkz0HYeRK/F3axzwIHkqDEyZ lPWGYBXcUsoCmxfpc+RImixJTuh+wQtoZE65y57MjiCxjZVzGaJxVlpmeU5CZm5ugaGhjoGho a6RpaGuuamuslVukm6qWW6panFpfoGuollhfrFVfmJuek6OWllmxiBKaylIKDljsYTy1PP8Qo ycGkJMq70rAvWogvKT+lMiOxOCO+qDQntfgQowwHh5IEr1ghUE6wKDU9tSItMweYVGHSEhw8S iK8DSBp3uKCxNzizHSI1CnGQI5TzT2TmDlmNfUDySP3pgDJC2By3tGpQPLPexB5p3vaJGYhlr z8vFQpcV47kEECIIMySvPg1sAyxSVGWSlhXkYGBgYhnoLUotzMElT5V4ziHIxKwry6IFN4MvN K4K55BXQoE9ChSw70gBxakoiQkmpgbDE/VKdnwltr5Jbyl7unvczM5jmfkYLI3W+/zjXWO3se Cfe/vu3ud9U8yVucNddvT+eeW6m3ZmPQ0dnqVavkQ6yFfMozP9xONrQ6XLmXR778/w2tqi/8b 2vCXj/n/f9gmYzuGd7zWfeer3r5r+qX55GwdovjHhX77u1c189s76TnZKcYrPdYiaU4I9FQi7 moOBEAb7vTjg8EAAA=
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-5.tower-265.messagelabs.com!1536062028!98055!1
X-Originating-IP: [52.33.64.93]
X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass
X-StarScan-Received:
X-StarScan-Version: 9.14.24; banners=ecitele.com,-,-
X-VirusChecked: Checked
Received: (qmail 22705 invoked from network); 4 Sep 2018 11:53:52 -0000
Received: from us-west-2b.mta.dlp.protect.symantec.com (HELO EUR01-HE1-obe.outbound.protection.outlook.com) (52.33.64.93) by server-5.tower-265.messagelabs.com with AES256-SHA256 encrypted SMTP; 4 Sep 2018 11:53:52 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SdHv7V2CzLXHebTG9ylfLFy0TCSYEwy/6vkMBJfzRtE=; b=Hqsen5l+ApBDCx9Li93RmqPMyURK6MVrUstuz0RO3D0Cm6jNddG9mE3vBF0tRFGrJTwVoRoFMjHlAGlcDUD/6IdSnEDJrFlFwqV/ed92xpVbjT59+/PJ6HRqP3s3rWYjkRhThrloBfIA2YexpultUt5xYbDev2IAl9dlM2+owPo=
Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com (10.167.226.155) by DB5PR0301MB1959.eurprd03.prod.outlook.com (10.167.227.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1101.14; Tue, 4 Sep 2018 11:53:45 +0000
Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com ([fe80::95ea:6ef4:60c3:bc68]) by DB5PR0301MB1909.eurprd03.prod.outlook.com ([fe80::95ea:6ef4:60c3:bc68%2]) with mapi id 15.20.1101.016; Tue, 4 Sep 2018 11:53:44 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: Krzysztof Szarkowicz <kszarkowicz@gmail.com>
CC: "Ali Sajassi (sajassi)" <sajassi@cisco.com>, Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>, Rotem Cohen <Rotem.Cohen@ecitele.com>, Shell Nakash <Shell.Nakash@ecitele.com>, "bess@ietf.org" <bess@ietf.org>, Ron Sdayoor <Ron.Sdayoor@ecitele.com>
Thread-Topic: [bess] A question regarding Single-Active ES redundancy mode and DF election in RFC 7432
Thread-Index: AdRCuX4OWvLxpG+GTwSFScLNHhlNZwBOYp8AAA2H9jAAAZwhAAAEESZw
Date: Tue, 04 Sep 2018 11:53:44 +0000
Message-ID: <DB5PR0301MB1909D1A31AC6B9C1B9EC443C9D030@DB5PR0301MB1909.eurprd03.prod.outlook.com>
References: <DB5PR0301MB1909252ACFD629C614D3C9F29D0D0@DB5PR0301MB1909.eurprd03.prod.outlook.com> <E8C974A3-8D6A-4B21-91AA-766C8E7DE8EF@cisco.com> <DB5PR0301MB1909879542132AF7A6C01AF59D030@DB5PR0301MB1909.eurprd03.prod.outlook.com> <8C36BC2A-377E-44AD-8D4F-9067126E7A62@gmail.com>
In-Reply-To: <8C36BC2A-377E-44AD-8D4F-9067126E7A62@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.234.241.1]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB5PR0301MB1959; 6:3wDs9IDDKxlWLCRcxlBRGeaQusdyf3QrAYpenYlTyrzcfu59qdIWYkenJf9VN68LyiHQ3sbd1JAaRj8wPpACLGFXBoUGB+YGKO6lJeuPBpEbyatA1A5p+ZkpsAxmKh/1ZT8SkTsK6Bt0s9n4QNJqZbVpADlEipgY3BTUpzBug/mSHX1eXeTNt5XQ47NzBXlZBnsVKLRzGiqSb6kegkqGL1YoaBYt0fXrVg2lpPt3dnoDjqTYTIMwlBsZe0X5mac6XMci05EIoXGrAwgQIddMrQTTOQUq8+lmLo7mED80Mdr7xC9EW5xPtuBPEokBISMo2/rkGesFXJrRt8QQXFE/H2BhG4UBrIh4byVpU1nu3I+XLNDKkKz0mz4i1hnwWlojW9vAu6YHC3G5BAPPWieouQI82TBoNu9FacKAuh7sd+oHVdTdQGwIwixKQzdY8mEXbXI24+MsV1JYb6/HZWIseQ==; 5:tbcbpbkEOWzDw0vGp/pt97S1Qu0FJdjqAZeN47uuVvNO2hPWMmFR4FD3DRefpowzhef21Mba1HNOoxRWsthyo9w9bzRaK2h/98ZxYkzL47QHXHvqpqpQuQE7J6Qy1GxvS7WShdQ1c5r8XP2b6qsg1CpgwmYxeTiLLy79pcJZaxw=; 7:LbyDgQjN1cl2L4Ew09yEct4FAopctX+IfxysYyc3GIGcA69hJLJp9gURTKZg5+H7ua54zHFRYyzUm7JQmFl39snf/mlKyISaXaX08TNXM+TUo9qDnWLRXT3vx1O9giV5L1QZ+1JzBBtaOe+3v0rICGgoMnnYMBT12yTA+tZyxjJGY5OufOwceNnZqyYB/wcL4xcO36v3cJMbp6iP7id9gC1WEY849k/Bwe4oeqD/vJWwtIMD/rwpuG5+OpCIfIsb
x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR;
x-ms-office365-filtering-correlation-id: c206df69-d97e-411d-d376-08d6125d1102
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DB5PR0301MB1959;
x-ms-traffictypediagnostic: DB5PR0301MB1959:
x-microsoft-antispam-prvs: <DB5PR0301MB19590BE8898732EB08E9AB169D030@DB5PR0301MB1959.eurprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(85827821059158)(95692535739014)(21748063052155)(279101305709854)(21532816269658);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231311)(944501410)(52105095)(3002001)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(201708071742011)(7699016); SRVR:DB5PR0301MB1959; BCL:0; PCL:0; RULEID:; SRVR:DB5PR0301MB1959;
x-forefront-prvs: 0785459C39
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(366004)(39860400002)(346002)(136003)(54094003)(51874003)(252514010)(189003)(199004)(14454004)(68736007)(99286004)(2906002)(6436002)(8936002)(790700001)(476003)(229853002)(53936002)(93886005)(6116002)(486006)(3846002)(54896002)(7696005)(6306002)(76176011)(11346002)(236005)(8676002)(33656002)(446003)(4326008)(9686003)(5250100002)(55016002)(6916009)(74316002)(316002)(6506007)(106356001)(105586002)(66066001)(53546011)(7736002)(26005)(102836004)(186003)(25786009)(86362001)(19609705001)(72206003)(107886003)(1411001)(6246003)(2900100001)(966005)(606006)(39060400002)(54906003)(256004)(81166006)(81156014)(478600001)(5024004)(97736004)(5660300001)(14444005); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR0301MB1959; H:DB5PR0301MB1909.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: bhQ7VY57QBRRGsfxKuEmewyF9JhJ57S05ZOYGzANUmtmTB6iNiRX47NvTrkHcu8LMh7XkBFSLGR/97uxeJIX2HaTw0tGU/ch+Fup6mkESD8rAAMNK4gGqHgEJCepkjCWSilZhU/Q6c/3shuOc55SszL2gNs9B3FgqLv3D/jJE1X1GxffNJL6JNQQSYyChDOFqywWreVlxklJC2+vsnIWiSFK6/OerdoInttyHJ7H5C5jWh7U9o2ahuU/AN1Z6XvD9VE/UD6ra8ukik4YzIdevPa6rM9scN/xtSEfutj+6SpwF1bfow/hS7cFqo25pNfTwW62dR1GVMIJX8uupFBKdPYNvckgLogS18TXt9AJXaE=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB5PR0301MB1909D1A31AC6B9C1B9EC443C9D030DB5PR0301MB1909_"
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c206df69-d97e-411d-d376-08d6125d1102
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2018 11:53:44.5222 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR0301MB1959
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/i75664rxiO9ABU1q16IpmKl-ZeM>
Subject: Re: [bess] A question regarding Single-Active ES redundancy mode and DF election in RFC 7432
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.27
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: Tue, 04 Sep 2018 11:53:59 -0000

Krzysztof,
Lots of thanks for your email. If I understand you correctly, it actually replaces Single-Active Redundancy Mode with the Port-Active one as defined in the corresponding draft<https://tools.ietf.org/html/draft-brissette-bess-evpn-mh-pa-01> (it also uses the Preference-Based DF Election<https://tools.ietf.org/html/draft-ietf-bess-evpn-pref-df-01> mechanism but tweaks it in such a way that it selects the same DF for all VLANs).

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com

From: Krzysztof Szarkowicz [mailto:kszarkowicz@gmail.com]
Sent: Tuesday, September 4, 2018 12:14 PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Cc: Ali Sajassi (sajassi) <sajassi@cisco.com>; Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>; Rotem Cohen <Rotem.Cohen@ecitele.com>; Shell Nakash <Shell.Nakash@ecitele.com>; bess@ietf.org; Ron Sdayoor <Ron.Sdayoor@ecitele.com>
Subject: Re: [bess] A question regarding Single-Active ES redundancy mode and DF election in RFC 7432

Hi Sasha,

To use LAG in A/S mode on per VLAN basis, you can use ‘hack’, where you use preference-based DF election (draft-ietf-bess-evpn-pref-df) to ensure with the configuration that *all* VLANs on given ESI use PE1 as DF, and *all* VLANs on that ESI use PE2 as non-DF. Then, you need to have a mechanism to signal from PE2 to the CE the link standby status (e.g. via LACP, as used in MC-LAG deployments; or, I could even imagine per link CFM/LFM/E-LMI), so that CE doesn’t use link to PE2.

Thanks,
Krzysztof


On 2018-Sep-04, at 10:39, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>> wrote:

Ali,
Lots of thanks for a prompt and detailed response.
It matches my understanding of the situation with Single-Active Redundancy Mode of Ethernet Segments in EVPN.
In particular, your confirmation that “You cannot use LAG to do active/standby on a per VLAN basis (aka EVPN single-active)” was quite important.

I have also noticed that Single-Active is not mentioned at all  in RFC 8388<https://tools.ietf.org/html/rfc8388>. I wonder what this means with regard to actual deployment of this mode.

Last but not least, I wonder if the expired draft<https://tools.ietf.org/html/draft-brissette-bess-evpn-mh-pa-01> on Port-Active multi-homing mode for EVPN will be refreshed and if, as part of such refresh, any details on the control plane of EVPN would be provided.

Regards, and, again, lots of thanks,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Tuesday, September 4, 2018 8:00 AM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>; Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com<mailto:Michael.Gorokhovsky@ecitele.com>>; Shell Nakash <Shell.Nakash@ecitele.com<mailto:Shell.Nakash@ecitele.com>>; Ron Sdayoor <Ron.Sdayoor@ecitele.com<mailto:Ron.Sdayoor@ecitele.com>>; Rotem Cohen <Rotem.Cohen@ecitele.com<mailto:Rotem.Cohen@ecitele.com>>
Subject: Re: A question regarding Single-Active ES redundancy mode and DF election in RFC 7432

Hi Sasha,

I don’t see any contradiction between the two statements from RFC 7432 that you mentioned below. For All-Active, DF election is for BUM traffic of a given VLAN (or group of VLANs in case of VLAN bundling) in the egress direction toward an ES. For Single-Active, DF election is for all traffic of a given VLAN (or group of VLANs …) in both directions of an ES. Now with respect to notification of active VLANs to a CE device: MVRP mechanism that is mentioned in the RFC is an IEEE standard way of doing such thing. However, if the CE support E-LMI, then that protocol can be used as well. Regarding LAG, it can be used to connect a CE in an active/standby mode where one link is active and another link in standby mode (assuming two-link bundle). You cannot use LAG to do active/standby on a per VLAN basis (aka EVPN single-active).

I will be travelling over next few days with limited email access, so please expect some delay for my responses.

Cheers,
Ali

From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>>
Date: Sunday, September 2, 2018 at 6:09 AM
To: Cisco Employee <sajassi@cisco.com<mailto:sajassi@cisco.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>, Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com<mailto:Michael.Gorokhovsky@ecitele.com>>, Shell Nakash <Shell.Nakash@ecitele.com<mailto:Shell.Nakash@ecitele.com>>, Ron Sdayoor <Ron.Sdayoor@ecitele.com<mailto:Ron.Sdayoor@ecitele.com>>, Rotem Cohen <Rotem.Cohen@ecitele.com<mailto:Rotem.Cohen@ecitele.com>>
Subject: A question regarding Single-Active ES redundancy mode and DF election in RFC 7432

Ali and all,
I have a question regarding one of the aspects of RFC 7432, namely operation of the default Designated Forwarder (DF) election process on an Ethernet Segment (ES) that operates in the Single-Active Redundancy Mode.

RFC 7432 defines the Single-Active Redundancy Mode in Section 3 as following:
“Only a single PE, among all the PEs attached to an Ethernet segment, is allowed to forward traffic to/from that Ethernet segment for a given VLAN”.

The same RFC in Section 8.5 also specifies that the DF for a specific VLAN on a multi-homed Ethernet segment (ES) is the only PE attached to this segment that is responsible for sending BUM traffic for this VLAN to the CE. It also defined the default DF election procedure that elects a single “live” PE on the specific ES as the DF for each specific EVI that is represented on this ES.

These two definitions look contradictory to me, because:

  1.  The default DF election procedure only involves the PEs attached to the specific ES
  2.  In the Single-Active Redundancy mode the elected DF for a specific VLAN must also be the only PE that is allowed to forward traffic received with this VLAN from the CEs to the peer PEs. It is not clear to me, how this can be achieved.

     *   The RFC mentions MVRP as a possible method to notify the attached CEs that a specific PE is NOT a DF for a specific VLAN in the case of an ES that operates in the Single-Active Redundancy Mode. Does this mean that CEs that are attached to a multi-homed ES operating in Single-Active Redundancy Mode SHOULD support MVRP?
     *   Are there any alternatives to MVRP that can be used for this purpose. In particular, is it possible to use Ethernet Local Management Interface (E-LMI) as defined in MEF-16<http://www.mef.net/resources/technical-specifications/download?id=42&fileid=file1> for this purpose?
     *   The RFC mentions LAG as the method to connect the CE to a multi-homed ES operating in the All-Active Redundancy Mode. Is it possible to connect a CE that uses LAG to a multi-homed ES operating in the Single-Active Redundancy Mode?

Your feedback would be highly appreciated.

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________
_______________________________________________
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________