Re: [bess] A question about RFC 8317

Aldrin Isaac <aldrin.isaac@gmail.com> Sun, 27 January 2019 01:22 UTC

Return-Path: <aldrin.isaac@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 015CA12896A for <bess@ietfa.amsl.com>; Sat, 26 Jan 2019 17:22:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 4MZjc0wbnFKp for <bess@ietfa.amsl.com>; Sat, 26 Jan 2019 17:22:02 -0800 (PST)
Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (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 8088A1288BD for <bess@ietf.org>; Sat, 26 Jan 2019 17:22:01 -0800 (PST)
Received: by mail-vs1-xe2a.google.com with SMTP id x64so7862251vsa.5 for <bess@ietf.org>; Sat, 26 Jan 2019 17:22:01 -0800 (PST)
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=druEqq7d2XNQDvVuPbwhKwOMd/U87Dpw4SZ0X0dO3Qg=; b=MXT5zKqxtJcflKm9o8w3Dl3rAklGNj6sduGuyDmLDR/r1aCrJnnXjsq5sQio9T7I0A 9wXgqudYpxRt6E1odTvL5edFv1rxzAuxGrsowd6DU+1Cm3iysC48rTv8ist/CB5Cgz9Z 5OS+hEmxuAwjnjcdmW2mASSO0vCOC14s1VS2lbEkSTRtNP42stLtJsiDWI3+bQCYEcH4 jk4StcYskbQzZJeteyL+gO8gKBe4RIy6VFh6B8t2thPrYaDSko2ER0lQtqtU5+w0XbzH e2Mu50U8yxRw4140MywFeObEp25WmBQV4uTjcTDV7fyFx6Wx5SJMVb+AslcnZWUiPK9l ZObQ==
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=druEqq7d2XNQDvVuPbwhKwOMd/U87Dpw4SZ0X0dO3Qg=; b=eGc0F0Ua/w7C/iYnj7BiICQRyGDl1nBbA4Qw1G5Mx8a9veW4KKS7qjXaCUKh4p3KEc rlS1rD9ljHrk22JTqLfUS+OyyKo47/9mToeiWUXxJS3mCgbdPguiVNSLgQjn7JuEl80b zP7VGJai4ZvZnS7A2gNgPZFC9QKoVN2oEZt3iWizSHjUnlZDPQMxw0E4nuPfEy0K2PVx QEoIYKgSjXjoowLmvSX0MvsHv3LoL5HpvYO5FDdaD2KuBXiNeYDWVH+uL++b+BgMaToE /Nm/J8EMRRFsQMPdftCoOy344XpJtg+2Q1u7bJZ0NiqAw1dUgDjCK7VHAIGrdN4EgnMk +ikA==
X-Gm-Message-State: AJcUukdViZfTByDEcSjeNd9zvq0cNtjuI7GDSpkIYPL5Jaxv8R502YJP uI/jHqxEwN3Mqf/Lf8revRcAKNRjuGVGx2SYJuk=
X-Google-Smtp-Source: ALg8bN5WapCRP/U4vm7tHX5jkpZI72TfDGLFPvykcMNhiSDLC/lghMRfAtmBezzEZUdQVb4gKg09Ko1elhdlseKiseE=
X-Received: by 2002:a67:e983:: with SMTP id b3mr6827850vso.231.1548552119383; Sat, 26 Jan 2019 17:21:59 -0800 (PST)
MIME-Version: 1.0
References: <AM0PR03MB38289E905EE9421BA529727B9DBF0@AM0PR03MB3828.eurprd03.prod.outlook.com> <7A95B86B-03C4-4D11-8A37-FFCB98BFA44B@nokia.com> <AM0PR03MB3828D22EFE13890EB08419459DB80@AM0PR03MB3828.eurprd03.prod.outlook.com>
In-Reply-To: <AM0PR03MB3828D22EFE13890EB08419459DB80@AM0PR03MB3828.eurprd03.prod.outlook.com>
From: Aldrin Isaac <aldrin.isaac@gmail.com>
Date: Sat, 26 Jan 2019 17:21:48 -0800
Message-ID: <CAOA2mbx74nO2jCDrQCS69Ob8WdDgg8cEfYAWgyJDq7uVnEML1w@mail.gmail.com>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Cc: "Ali Sajassi <sajassi@cisco.com> (sajassi@cisco.com)" <sajassi@cisco.com>, "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>, "John E Drake (jdrake@juniper.net)" <jdrake@juniper.net>, "Samer Salam (ssalam)" <ssalam@cisco.com>, "ju1738@att.com" <ju1738@att.com>, "sboutros@vmware.com" <sboutros@vmware.com>, "bess@ietf.org" <bess@ietf.org>
Content-Type: multipart/related; boundary="000000000000febc5b058066623c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/3Qs7njzwUVAWVA8qmSrLYNlRS8Y>
Subject: Re: [bess] A question about RFC 8317
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, 27 Jan 2019 01:22:05 -0000

Hi guys,

If we instead consider that the two-RTs scheme from operator point-of-view
is really a Root-only and Leaf-only MAC-VRF scheme (vs mixed root/leaf
MAC-VRF). Suppose all routes from a leaf VRF are marked with a “leaf
indication”. Suppose we use only one RT where leaf MAC-VRF rejects any
route with “leaf indication” except those of local active ESI which are
processes normally. Would we be able to support basic E-Tree behavior for
non-MPLS tunnel types using such a scheme?

Need a way to address basic E-tree with multi-homing in EVPN VXLAN/Geneve,
namely PVLAN.

Cheers,
Aldrin
On Thu, Dec 20, 2018 at 11:42 PM Alexander Vainshtein <
Alexander.Vainshtein@ecitele.com> wrote:

> Jorge,
> Lots of thanks for a prompt response.
> My conclusion js tbat the "two RTs" scheme should be used with special
> care in E-tree solutions. This was not my impression from the first reading
> of 8317.
>
> Since the "two RTs" scheme is very popular in hub-and-spoke" solutiobs for
> IP VPN, the fact that it is not the universal answer in EVPN E-Tree
> deserves some expla ation IMHO- but I do not see how this can be done in
> IETF.
>
> Thumb typed by Sasha Vainshtein
>
> ------------------------------
> *From:* Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com
> >
> *Sent:* Thursday, December 20, 2018 7:31:20 PM
> *To:* Alexander Vainshtein; Ali Sajassi <sajassi@cisco.com> (
> sajassi@cisco.com)
> *Cc:* Samer Salam (ssalam); John E Drake (jdrake@juniper.net);
> ju1738@att.com; sboutros@vmware.com; bess@ietf.org
> *Subject:* Re: A question about RFC 8317
>
>
> Hi Sasha,
>
>
>
> What you are explaining is correct.
>
>
>
> PE3 would flood anything for which MAC DA is unknown to both local ESes.
> That is normal behavior, only that in this case CE-1’s MAC will not be
> learned on PE3 *until CE-1 hashes the traffic to PE3 and not only PE2*
> (which will happen if you have a decent number of flows). **Technically
> speaking**, the E-Tree solution works since you don’t have leaf-to-leaf
> communication. However, I would not use the two RT solution in this
> scenario since it could create unnecessary flooding to local ESes as you
> describe.
>
>
>
> For this scenario I would always use a single RT per EVI, ingress
> filtering for unicast (based on the leaf indication on MAC/IP routes), and
> egress filtering for BUM based on leaf label, as explained in RFC8317.
>
>
>
> My two cents.
>
>
>
> Thank you.
>
> Jorge
>
>
>
>
>
> *From: *Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
> *Date: *Thursday, December 20, 2018 at 12:30 PM
> *To: *"Ali Sajassi <sajassi@cisco.com> (sajassi@cisco.com)" <
> sajassi@cisco.com>
> *Cc: *"Samer Salam (ssalam)" <ssalam@cisco.com>om>, "John E Drake (
> jdrake@juniper.net)" <jdrake@juniper.net>et>, "ju1738@att.com" <
> ju1738@att.com>gt;, "sboutros@vmware.com" <sboutros@vmware.com>om>, "Rabadan,
> Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>om>, "
> bess@ietf.org" <bess@ietf.org>
> *Subject: *A question about RFC 8317
>
>
>
> Ali and all,
>
> I have read RFC 8317 <https://tools.ietf.org/html/rfc8317>, and I would
> like to clarify a question dealing with Leaf ACs of an EVPN-based E-Tree
> service on All-Active Multi-Homed Ethernet Segments (MH ES).
>
>
>
> The reference model for my question is shown in the Embedded diagram below.
>
>
>
> [image: cid:image002.png@01D49865.895588B0]
>
>
>
> It shows an EVPN E-tree service with one Root customer site and two leaf
> customer sites, where each Leaf CE is dual-homed to the same pair of PEs
> using two different All-Active multi-homed Ethernet Segments.
>
>
>
> Suppose that the scheme with two RTs (one identifying the Root site and
> the other identifying the Leaf sites) is used as described in 4.3.1.
>
>
>
> Suppose also that each MAC-VRF uses per MAC-VRF label assignment as
> defined in section 9.2.1 of RFC 7432, i.e., advertises exactly one EVPN
> application label that identifies it as the Egress MAC-VRF, while the
> disposition of the received Ethernet frame within this MAC-VRF is based on
> the destination MAC address. In this case the per MAC-VRF label can be also
> used as the “aliasing” label in the per EVI EAD route.
>
>
>
> PE-1 will receive and accept per EVI EAD routes for both MH ES for PE-2
> and PE-3 with the corresponding “aliasing” labels.
>
>
>
> Suppose that MAC-VRF in PE-2 learns some {MAC, IP} pair  {X, Y}  locally
> from the Leaf CE-1 and advertises this pair in the EVPN MAC/IP
> Advertisement route. With the “two RTs” scheme this route will be accepted
> by the MAC-VRF in PE-1 but it will not be accepted by the MAC-VRF in PE3.
> As a consequence:
>
> -          MAC-VRF in PE-1 will know that this pair has been learned from
> the “blue” all-active MH ES, and therefore can decide to send locally
> received unicast frames with destination MAC address X to PE-3 using the
> corresponding “aliasing label”. No other labels will be included in the EVN
> encapsulation of such  frames because they are received from the Root AC.
>
> -          MAC-VRF in PE-3 will not know anything about MAC address X,
> therefore, when it receives an EVPN-encapsulated frame with this
> destination, *it will treat it as an “unknown unicast” and flood it to
> both Leaf CE-1 (where it should be sent) and to Leaf CE-2 (where it should
> not be sent)*.
>
>
>
> Is this what is really supposed to happen in this scenario? If not, what
> did I miss in the E-tree EVPN solution?
>
>
>
> Regards, and lots of thanks in advance,
>
> Sasha
>
>
>
> Office: +972-39266302
>
> Cell:      +972-549266302
>
> Email:   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
> https://www.ietf.org/mailman/listinfo/bess
>