[bess] Comments on draft-ietf-bess-evpn-irb-mcast

Ashutosh Gupta <ashutoshgupta.ietf@gmail.com> Wed, 15 August 2018 08:07 UTC

Return-Path: <ashutoshgupta.ietf@gmail.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0E868130EFF; Wed, 15 Aug 2018 01:07:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 00uXTVQ0s0eC; Wed, 15 Aug 2018 01:07:25 -0700 (PDT)
Received: from mail-pl0-x231.google.com (mail-pl0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) (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 20415130DFC; Wed, 15 Aug 2018 01:07:25 -0700 (PDT)
Received: by mail-pl0-x231.google.com with SMTP id g1-v6so209839plo.2; Wed, 15 Aug 2018 01:07:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=e4pS50WJR0BQWJY7sPTdfv07SMFN1bHziZNEumxHRKk=; b=o+XYmq9KHEd1+D2G3laKzgeqWWqRHtbkKTHtNpzAFM48BUVKI1h+89YKCCuDi7l7ts R/6jCWIyJ0T8TcOsVJZpEedBO/d1/r2rwiOuzXKqvh8x9kOYUyODg+QruLDTpES8UgPG g2cWj1wenHg1Np/NT0bEP+qKrcMtHNO6mZ/Vzs0WspP1S4NqciVGlW6VEkAx/BiD+rJp MrqCNGn5GU+q1WblOajZ83+bvvJia1A3WQkAtgZPNsFZwryw1cohzFL6QozhhTwEo2SF IatO3Mrj2yTAQnn0JaC+uLQZxoSDoxYA9aTG2TjkDK6eJKjSi27d89DKyQ8QkdmafaQP AdVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=e4pS50WJR0BQWJY7sPTdfv07SMFN1bHziZNEumxHRKk=; b=baNMxBx9mlRg818uY5/zLE7nYPaeu6aGGfB1a0ISyzYhZ/ynhAVhGWo5kDyggEZ2Dv 6RG/Q0X5vCnTIkDxZmmFhnRc5sRglLq+rWADhRffxB7nyu8K0spemqj2zM+nt8J1hiJG OoeAwOMJ5W28JdKwdqCMZtHY4L9SLdJh1mlsJsZYaGzOpoiiajmnfn1VFWWqhi6GS/G/ qfpUPF3CxKbKEx5XGZNFyQVxwa3cJIRCJ3KTm8xZ71sxOkST5kEON0gywP3Ys+mTVx7t NRcytQmUH7RCbi97id6wh/vXkanf6BnxpZJO0NjY5swhx0lJqK2tjZcuqvUMrpIbwDLf gjMQ==
X-Gm-Message-State: AOUpUlH9fCCqfn3M2u8eY37yGvStcBVdXe0xMVkn6uHf1s3mVFvJqzEd KAD3ffVH6XIDZnP9KUr2hHKWEyYmndOJ94pwwoHBuw==
X-Google-Smtp-Source: AA+uWPwJqZe+O00XQs/dFFNbOWq4fnQuxD5GrWK5a6ozJjXa7ZHH9GzjzvcQuWSlQ4M0zz+lm6avZUu4LSz/hYl/cp4=
X-Received: by 2002:a17:902:20e3:: with SMTP id v32-v6mr23595297plg.232.1534320444575; Wed, 15 Aug 2018 01:07:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a17:90a:4ce3:0:0:0:0 with HTTP; Wed, 15 Aug 2018 01:07:24 -0700 (PDT)
From: Ashutosh Gupta <ashutoshgupta.ietf@gmail.com>
Date: Wed, 15 Aug 2018 01:07:24 -0700
Message-ID: <CAPAoC9SBhHExZ8uhbN2c8L2-rREsAk9X4V=Af__mrdmB4T9pEA@mail.gmail.com>
To: draft-ietf-bess-evpn-irb-mcast@ietf.org
Cc: bess@ietf.org
Content-Type: multipart/alternative; boundary="000000000000121501057374d119"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/LWhph75lyBvaSlqOgtXVomxdvBo>
Subject: [bess] Comments on draft-ietf-bess-evpn-irb-mcast
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: Wed, 15 Aug 2018 08:07:27 -0000

Hi Folks,

I have following comments on draft-ietf-bess-evpn-irb-mcast. I also compare
it to draft-sajassi-bess-evpn-mvpn-seamless-interop, which utilizes
existing MVPN technology to achieve mcast-irb functionality in EVPN.

*1. Re-branding MVPN constructs into EVPN *
*evpn-irb* draft proposes a lot of MVPN constructs into EVPN.
Originating multicast
receiver interest "per PE"  instead of "per BD", use of selective tunnels
are few examples. If solution really is achievable through MVPN, why do we
need to re-brand it in EVPN?

*2. Scale of BGP routes*
*evpn-irb* solution mandates a PE to process and store all IMET NLRI's from
all peer PE's in tenant domain (as opposed to processing and storing only
NLRI's for BD's it has locally present). This is proposed because multicast
traffic could be originating from any PE in any BD. To put this in
perspective, lets take an example of a tenant domain with 101 PE's with
each PE having 1000 BD's. Each PE has at most 10 BD's common with any other
PE in network. In this case PE1 will have to process and store, 100 (remote
PE's) x 1000 (BD's per PE) x 1 (IMET per BD) = 0.1 Million IMET routes.
Essentially, it is of order *"Num of BD's" x "Num of PE's"*.

Whereas for *seamless-interop* solution, a PE would need to process and
store 100 I-PMSI (IMET equivalent in MVPN) routes, means one route from
each peer PE. . This is of order *"num of PE's".* It should be noted that
VxLAN supports and max of ~16 million BD's thus *evpn-irb* solution results
in huge overhead per PE if compared with *seamless-interop*.

*3. Control plane scale in fabric / core *
Also each PE one additional Tunnel per BD apart from existing BUM tunnel.
Essentially one tunnel for B+U and another for M. This is proposed to avoid
all B+U traffic in the BD1, indiscriminately reaching all PE's in domain,
irrespective of whether they have BD1 configured locally or not. This
increases the state in fabric by *"num of PE" x "num of BD"*. In above
example it would again come to 0.1 Million additional tunnels.

*seamless-interop* solution uses one tunnel per PE, so 100 additional
tunnels to achieve same objective.

*4. Data Plane considerations*

*4.1.* The data-plane nuances of solution has been underplayed. For
example, if a PE1 has a (S, G) receivers in BD2, BD3 till BD10, whereas
source S belongs in BD1 subnet on PE2. And if BD1 is not configured locally
on PE1, a special BD (called SBD) is programmed as IIF in forwarding entry.
Later if BD1 gets configured on PE1, it would cause IIF to change on PE1
from SBD to BD1. This would result in traffic disruption for all existing
receivers in BD2, BD3 till BD10. It should be noted that no state changes
are observed in any of the receiver BD's. This is a significant drawback of
the solution given the latency requirement of applications running in
data-centers. Additionally, since host mobility and on-demand BD
configuration are critical functionalities for DC solutions, such case
can't be discounted.

*4.2. *Also, *evpn-irb* solution proposes to relax the RPF check for a (*,
G) multicast entry. This poses a great risk of traffic loops especially in
transient network conditions in addition to poor debug-ability.

*seamless-interop* solution doesn't possess these drawbacks and any BD
configuration or de-configuration wouldn't cause any change in existing
forwarding state.

In nutshell, even after borrowing MVPN constructs, *evpn-irb* solution
presents significant overhead in comparison to *seamless-interop* for
modern day data-center use-cases where flexible workload placement,
workload mobility and data-plane efficiency are critical features.