Re: [bess] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop

Ashutosh Gupta <> Wed, 15 August 2018 07:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E33A129619 for <>; Wed, 15 Aug 2018 00:56:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yuDYDC7n0VdW for <>; Wed, 15 Aug 2018 00:56:56 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::444]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6527E129385 for <>; Wed, 15 Aug 2018 00:56:56 -0700 (PDT)
Received: by with SMTP id d4-v6so223025pfn.0 for <>; Wed, 15 Aug 2018 00:56:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6LdyyeixBlTbTFIKg/8h4s6E/wioF7IMUcW2EDNOE0A=; b=pY7hblviHzA6ZQBka20Fl7ZfSrGi0NXuJjpQMwy4XMQ1uypfTrHvHLSeBlN+wgmqej 4tpHL6gARuN9maU4Scv5klzLsFbc364B+JimXxyqt2p7Jhsb0n11BUSDW8dWKmi8Wkw+ 0oZNbyLIP8VxSFRwe8fyxDqeixqfhyWmmUCkRiuHqYkVdirI69SDf1mOKNDvYMv1UCOa NBY83EOiQaSLwhmeFpk/up+dhGvbJn2k+CAhrkMXzQBwcfuSdlAkgNvXhqD/T4LumbaI PyhcxWLfH40+DEMt3cHnwIShk50UlY9tqf+iPxFLGPHpbr7gTF3N9CuIKuLCoc+ApnQo mUmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6LdyyeixBlTbTFIKg/8h4s6E/wioF7IMUcW2EDNOE0A=; b=h50HNKWVI4Mz37yaXuvXAOB0PN6oXOPtRMflL6SG43ol1AN/4gnEVFBFyejmTckP46 SuNwyQbf7tAxju4Y8Xhh7p1W4mtZm3mFidshMgQ3sltqQXh2Wf1C9nti+FTmz8JyVQnG 3ZH+xHJVgoDEArf3v8kDHp1qrA33CNWoqXODbRenj2YbDQIt+9jhRM/C7INbizbMBbE3 XA6RwRk+ZqCnUOteH+6noRJjnCQSurB/Iq1pbjHjx4kw+HRK7WHIIQ0t7t2fbDyJX2c8 p4LdJPA/y0BrQ031OJZDiRrcGFGWcK6RhPmGbjtQlcnjthPlkGdYqbN/X5XQht9IwLck kvew==
X-Gm-Message-State: AOUpUlFdp76rQas+iG2mazZRVzdx90MFFg3bI7Xsfzv8JBKDVigY+KoI VmM9UYArtAGR4/ousByBKKyHL8PnTD4BuWIH1lg=
X-Google-Smtp-Source: AA+uWPxliApN0WWdOn91qVa6ZNDcuXOWwXUDsu7YTZnEBY6DKMWd2ymbqti6/5G5V01LjyK79viHxy6oIP7cAzYP8Qo=
X-Received: by 2002:a62:9f1d:: with SMTP id g29-v6mr26161776pfe.207.1534319816012; Wed, 15 Aug 2018 00:56:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a17:90a:4ce3:0:0:0:0 with HTTP; Wed, 15 Aug 2018 00:56:55 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Ashutosh Gupta <>
Date: Wed, 15 Aug 2018 00:56:55 -0700
Message-ID: <>
To: "Jeffrey (Zhaohui) Zhang" <>
Cc: Ali Sajassi <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000009af6a1057374ab50"
Archived-At: <>
Subject: Re: [bess] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Aug 2018 07:56:59 -0000

Hey Jeffrey,

Thanks for your comments & please find my responses inline *<AG>* .

On Fri, Jul 20, 2018 at 9:53 AM, Jeffrey (Zhaohui) Zhang <
> wrote:

> Hi Ali,
> Here are the comments that I did not get a chance for in the meeting today.
> Regarding "ttl decrement" and "src mac change":
> ------------------------------------------------------------------
> Since "bridging/switching in the same BD" is not put down as a requirement
> in the spec but rather discounted citing "emulation", the listed
> "requirements" should be changed to "properties" as well - one could also
> argue that those may not be true requirements and could also discounted.

*<AG>* s*eamless-Interop* solution supports both intra-subnet and
inter-subnet forwarding which are the basic requirement along with
Efficient fabric utilization and Operational simplicity. More specifically,
having many discussions with customers we didn't come across any use-case
where strict intra-subnet bridging was needed along with inter-subnet
routing, so we can argue that "strict bridging/switching in the same BD" is
just an idealistic requirement.

Even if RFC7432 does not prove true ethernet service, "ttl decrement" and
> "src mac change" for intra-subnet traffic does NOT happen with RFC7432. In
> other words, this is a step-down from RFC7432.

*<AG>* It is not a step down since we are not losing any needed
functionality. Again, *seamless-interop* solution utilizes existing and
well deployed technology (MVPN) instead of re-defining all the constructs
of MVPN into EVPN. *evpn-irb-multicast* draft takes later approach and
achieves in-signification functionality gain at the expense of huge
overhead in control-plane (Explained on a separate thread). From our
customer interactions, we understand that Multicast is a complex technology
to deploy, operate and troubleshoot. So any amount of simplification
results in Opex reduction. Additionally, re-use of existing MVPN
implementation for additional EVPN use-cases results in quick
time-to-market with lower investment.

About the comment "MVPN also decrements ttl and change src mac address" -
> that's expected behavior because it is routing between subnets not "intra
> subnet", and no application that uses MVPN service has assumption on
> constant TTL and src mac.
> More regarding the "requirements" (or "properties")
> -----------------------------------------------------------------------
> With the other solution (evpn-irb-multicast, aka OISM), if every EVPN PE
> runs the MEG procedures then the same set of "requirements" is also
> achieved - it is also "seamless interop" but based on the OISM procedures,
> but that does not "translate into this method" (as defined in the *seamless-interop
> *draft) (I think that's what you mentioned when addressing Jorge's
> comment). What's more, it does not have the "ttl decrementing" and "src mac
> change" issue for intra subnet traffic.
> *<AG> *The point was made that once multicast traffic reaches MVPN
domain, it doesn't belong to any specific BD and hence intra-subnet and
inter-subnet receivers are treated similarly. Even with *evpn-irb-multicast*
solution, it would be the same unless a second copy of traffic is send over
BD specific tunnel.

Regarding "9.  DCs with only EVPN PEs"

> For comparison, the OISM method does not need any provisioning/procedures
> related to RP and registering. That is a significant simplification that an
> EVPN-only operator should be aware of.
> *<AG> * Same functionality is achieved in *s**eamless-Interop* by
utilizing SPT-only mode of MVPN in which shared multicast trees are not
formed in the core.

> Jeffrey
> Regards,

> _______________________________________________
> BESS mailing list