Re: [bess] About draft-brissette-bess-evpn-l2gw-proto-03

John E Drake <jdrake@juniper.net> Tue, 06 November 2018 16:59 UTC

Return-Path: <jdrake@juniper.net>
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 E37C812F1AB; Tue, 6 Nov 2018 08:59:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.171
X-Spam-Level:
X-Spam-Status: No, score=-1.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, 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=juniper.net
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 EqY4vdVneiPv; Tue, 6 Nov 2018 08:59:37 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 7052612F1A5; Tue, 6 Nov 2018 08:59:37 -0800 (PST)
Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id wA6GsIW8003822; Tue, 6 Nov 2018 08:59:35 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=Zks9Kt14EAZwHq6oErEbK7CvWOxYoxcH4ub05U1ita0=; b=0DA+XIkZCpgdeIFDkxXxFO/ngaOFQBDvS2OeFNdWw031wR2V6FGNbHjoKu2szzykPSjR dAB49ONRynUb1Zqiw/dim5c9BPLBQ+OGTLxXzATr18wX5nO7iyEsU+2yyLoKbq2ycyei IyxymCp3MWzklRGkSuLQCYNn8lAo+j8cb0r2CiPOu6/Xrs7IiQTkNWCAlxUBiY1g58CF gfreF7oInd6/OOpQk/ZJ6t/AjIRrl9wRgX6QtadjWM7VRIKA/NewWTFCxaAkrVKo9bJ7 ewsI0wI01t5b5IPipb6ZfFUKmWyeSJGXfqPnTSrww1ILwkuM7l1C9CCZJLoW8AdfP6MZ WA==
Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp0182.outbound.protection.outlook.com [216.32.181.182]) by mx0a-00273201.pphosted.com with ESMTP id 2nkeby82dd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 06 Nov 2018 08:59:35 -0800
Received: from BN7PR05MB4354.namprd05.prod.outlook.com (52.133.223.33) by BN7PR05MB4449.namprd05.prod.outlook.com (52.135.248.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.9; Tue, 6 Nov 2018 16:59:32 +0000
Received: from BN7PR05MB4354.namprd05.prod.outlook.com ([fe80::c494:2955:fd6c:4012]) by BN7PR05MB4354.namprd05.prod.outlook.com ([fe80::c494:2955:fd6c:4012%4]) with mapi id 15.20.1294.032; Tue, 6 Nov 2018 16:59:32 +0000
From: John E Drake <jdrake@juniper.net>
To: "Patrice Brissette (pbrisset)" <pbrisset@cisco.com>, "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>, "bess@ietf.org" <bess@ietf.org>, "draft-brissette-bess-evpn-l2gw-proto.authors@ietf.org" <draft-brissette-bess-evpn-l2gw-proto.authors@ietf.org>
Thread-Topic: About draft-brissette-bess-evpn-l2gw-proto-03
Thread-Index: AQHUdOwx/aMfxuqyz0+2Tgv3Lm4QIKVB60kAgAEIwWA=
Date: Tue, 6 Nov 2018 16:59:32 +0000
Message-ID: <BN7PR05MB43543C11DD9872F3716D3D8BC7CB0@BN7PR05MB4354.namprd05.prod.outlook.com>
References: <7BA1CB85-2E25-499F-A183-61C997A81B35@nokia.com> <D0B43760-3028-484D-AE8B-0F0B1E515EC8@cisco.com>
In-Reply-To: <D0B43760-3028-484D-AE8B-0F0B1E515EC8@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.0.400.15
dlp-reaction: no-action
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN7PR05MB4449; 6:sWYpvKOV+yWtI0skRXTPDyRzTkPQt3Ud3C60OR8Yy+o2Vm1o8pu9s88oXje7FDe2N3EMd08IRs26644eKNmRqLAcyPHjIg57a8/HFA3AdgioHSfjLeITkI/dLQLWLrFFcNC+qxHkvFwqkB2uqUNYNsORzPrE0+RR6sEZlDegmo+rlPbrfnWjRZqzBdes1wPlF0Sb11L81OlWEb7nI2yepBzi+sfhJ0rwTKgQk8PvJb0O2Y2n+P7qWwhlqvn5nPFM+KlR5Ls7a/3ghjSrSaCAnNGz1OuRJ0KKLE/dEuBujc9Hyvtt5yGeMNnKvboFpC6kxCvsU2o6YpW9LcpunuRWkosQNhDSUwNcFqm7xvpmiLlg8JeOEiAyILSDNAGM3Twyi/boO0XirHXVBV1rGFDRnNHNO5OEwqw3aT4RFRIEcDnIf48BNqiLzx1z0Zr+p2rgEixme9OeKJUla+2dkZMzgw==; 5:ULqUaPw9chmqQghiB5+yHWk0VjBCyf5U7IOw3/mvubJV5RDXo26JeGeecmncIoGCf+h9qE981bKHrz7R6/XQbhp88suaxxpwudo5SwD7yWIPPF90VMXG7+pIkURcYNw6Kc9302YXrHYchpEoRmcSqmYq13CqonckD7FidPKDSDs=; 7:DGj1teUQDeeotq5PpuGof4M5ys403pTHv0GOp4X2Ir4WiSybBqtYefDKSeC6/8WG6ACZ3P+uVB5TPppY+wW3dzmeE89o29lFbyUPzsHzzM/bgYUHJ2ie2ywhSKr83bZlL5MBGGTDm7Bfbotyh3X9kQ==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 308bd705-bb51-4962-cccd-08d64409393b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BN7PR05MB4449;
x-ms-traffictypediagnostic: BN7PR05MB4449:
x-microsoft-antispam-prvs: <BN7PR05MB444946809BF0839B6A95CC1FC7CB0@BN7PR05MB4449.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(83196854966205)(163750095850)(10436049006162)(195916259791689)(109105607167333)(82608151540597);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231382)(944501410)(52105095)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:BN7PR05MB4449; BCL:0; PCL:0; RULEID:; SRVR:BN7PR05MB4449;
x-forefront-prvs: 0848C1A6AA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(396003)(136003)(39860400002)(346002)(13464003)(199004)(189003)(11346002)(33656002)(561944003)(86362001)(2201001)(575784001)(74316002)(305945005)(7736002)(66066001)(25786009)(316002)(97736004)(6306002)(229853002)(6506007)(9686003)(53546011)(6436002)(99286004)(7696005)(76176011)(966005)(68736007)(110136005)(6246003)(478600001)(53936002)(55016002)(8936002)(81166006)(81156014)(8676002)(14454004)(6116002)(2501003)(3846002)(2906002)(5660300001)(71200400001)(106356001)(105586002)(71190400001)(2900100001)(476003)(486006)(26005)(446003)(19627235002)(14444005)(256004)(5024004)(102836004)(186003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR05MB4449; H:BN7PR05MB4354.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: zYutUSjFP8yqqjcU+cN9p83ktG7mWnw0Rgh05kOuEwN6gc8Q6LwmgWaJRXn+8NUDePeJTjSgvp+cq2L1RXzE7+GlxRtWXWFcJqiucUlcFkSE52IX8wKImAJdHzAkfLPyGoXKYVKq2VuGo8Z1PnwgU0eER8ZX/Yxk87FOR1Pl0lKdn28Zq+jFa5yIVp8IBU9ikohqNi4SnUdvwsYwRaXqbRiiLIZcPrVNuxuHOUUz9LE4WkKp1RkHrlXE/tRXxG+GwzzYQR4nnsKPxb3YRrUHgeWE+KIQze+GEiY+PBZwUwmxuAXxE0ZfXE4DpL6qu4u8dh6V+KjcQhOtj+fA1NxuKUnI5XNMV9syatyKf/KqnNk=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 308bd705-bb51-4962-cccd-08d64409393b
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2018 16:59:32.2877 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR05MB4449
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-06_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1031 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811060148
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/BTpqytkJ_wkL6IWSt2P_CbfaSA8>
Subject: Re: [bess] About draft-brissette-bess-evpn-l2gw-proto-03
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: Tue, 06 Nov 2018 16:59:40 -0000

Patrice,

I think it is much cleaner to treat the attachment of a set of L2GW PEs to an L2 network as a set of individual ESes, one per L2GW PE, as Jorge suggests.  This is because a remote PE accesses different parts of the L2 network through different L2GW PEs;  i.e., to a remote PE the connectivity looks like different sets of destinations associated with different ESes.

Yours Irrespectively,

John


> -----Original Message-----
> From: BESS <bess-bounces@ietf.org> On Behalf Of Patrice Brissette
> (pbrisset)
> Sent: Monday, November 5, 2018 7:49 PM
> To: Rabadan, Jorge (Nokia - US/Mountain View)
> <jorge.rabadan@nokia.com>om>; bess@ietf.org; draft-brissette-bess-evpn-
> l2gw-proto.authors@ietf.org
> Subject: Re: [bess] About draft-brissette-bess-evpn-l2gw-proto-03
> 
> Hi Jorge,
> 
> Please see my comments below ... <PATRICE>
> 
> Regards,
> 
> Patrice Brissette, Principal Engineer
> Cisco Systems
> Help us track your SP SR/EVPN Customer Opportunity/Status by filling these
> forms: Segment Routing <https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__app.smartsheet.com_b_form_185833ace35b4894b324dfb8afbd2060&d
> =DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-
> s_xXXup3HzvBSMRj5VE&m=JHaM715XuaFLBHtFogTkvMBGX9FJpdhm01YpjAk
> Tvj0&s=UkHEfjNPy44C3HNNU8QiEPpRGRJ6_gabZewtSN-cmqQ&e=> / EVPN
> <https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__app.smartsheet.com_b_form_136bd5c3a22641bf92316523e79d6f22&d
> =DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-
> s_xXXup3HzvBSMRj5VE&m=JHaM715XuaFLBHtFogTkvMBGX9FJpdhm01YpjAk
> Tvj0&s=cwPTHa9AP_hSi_jkXTbFtTcE1lujDqRDYXOaUWuUM7U&e=>
> 
> 
> 
> On 2018-11-05, 4:44 PM, "Rabadan, Jorge (Nokia - US/Mountain View)"
> <jorge.rabadan@nokia.com> wrote:
> 
>     Dear authors,
> 
>     Some comments about this draft:
> 
>     1- the draft uses some 'non-standard' terminology. Could you use RFC7432
> terminology please? An example of 'non-standard' term is EVLAG.
> <PATRICE> Will do
> 
>     2- the draft proposes a solution for something that works today without
> the need of a multi-homed Ethernet Segment or any new procedures:
>     - There are already EVPN deployments that use STP/G.8032 access rings.
>     - The two EVPN PEs that close the ring can participate of the ring protocol,
> therefore the received mac flush messages will withdraw the required
> MAC/IP routes.
>     - Since the remote PEs will forward normally based on their MAC FIB
> (populated by MAC/IP routes), there is no need to specify a new "Single Flow
> Active" forwarding mode. This is normal MAC based forwarding. Why do we
> need to create a new mode?? Can you please explain?
>     - Besides, by adding a bit in the ESI-label ext community different than the
> single-active bit, you make the solution non-backwards compatible.
> 
> <PATRICE> I'm not sure why you are mentioning the draft is NOT backward
> compatible. You need to explain that one. May I should add "remote PE not
> support single-flow-active bit may ignore this mode"
> <PATRICE> It is true you can support ring using single-homed and you are
> welcome to do so. However, there are important drawbacks. For example,
> how do you achieve ARP and MAC sync?
> 
> 
>     3- Section 6 - why do you define yet another extended community for mac
> flush, when we already have one? (RFC7623)
> 
> <PATRICE> It is true that we can reuse the MAC mobility from RFC7623. Note
> taken
> 
>     4- there is some value in the proposal though - the mass withdrawal (per-
> BD or per-ES) as opposed to per-MAC withdrawal may speed up
> convergence. Here is an alternative solution that can achieve the same thing
> and it's backwards compatible with RFC7432:
> 
>     On the L2GWs:
>     a) Define a single-homed non-zero ESI per L2GW PW. The ESI can be auto-
> derived easily as type 3/4 and be made unique in the network.
>     b) Since the ES is defined in a single PE, the ES routes will be filtered by the
> RR (use RTC) and won't ever reach other PEs. Alternatively you can disable
> the ES routes.
>     c) This L2GW ES will be single-active mode (although it does not matter
> much).
>     d) Since the ES is not shared across the L2GWs, each L2GW will always be
> DF for all the local VLANs.
>     e) Each L2GW will send AD per-ES and per-EVI routes for its ESI.
>     f) When the L2GW receives a mac-flush notification (STP TCN, G.8032
> mac-flush, TLDP MAC withdrawal etc.), the L2GW sends an update of the AD
> per-EVI route with the MAC Mobility extended community and a higher
> sequence number - note that we borrow this well-known mac flush
> procedure from RFC7623, only for AD per-EVI routes.
> 
> <PATRICE> As we demonstrated yesterday, there many cases where single-
> active or all-active are simply not working. Relying on single-homed is not
> sufficient even with an ESI. I already gave the example of ARP/MAC sync.
> 
> 
>     On the remote PEs:
>     g) The MACs will be learned against the ESIs, but there will only be one
> next-hop per ES. No aliasing or no backup. And RFC7432-compatible.
>     h) Upon receiving an AD per-EVI update with a higher SEQ number, the PE
> flushes all the MACs for the BD. If the PE does not understand the MAC
> Mobility ext comm in the AD per-EVI route, it won't do anything and will
> simply flush MACs based on MAC/IP route withdrawals.
>     i) Upon receiving an AD per-ES route withdrawal the PE will do mass
> withdrawal for all the affected BDs (this is the case where the L2GW local ES
> goes down).
> 
> <PATRICE> I think you are considering only failure visible by PE only.
> 
>     Please let me know your comments.
> 
>     Thank you.
>     Jorge
> 
> 
> 
> 
> 
> 
> _______________________________________________
> BESS mailing list
> BESS@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_bess&d=DwIGaQ&c=HAkYuh63rsuhr6S
> cbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-
> s_xXXup3HzvBSMRj5VE&m=JHaM715XuaFLBHtFogTkvMBGX9FJpdhm01YpjAk
> Tvj0&s=jVZqzygBj1QGRyzGojoLzg7tmopo2gc7R5DzUh2hgOY&e=