Re: [Idr] IDR heads up on BESS draft: BGP for SFC: draft-mackie-bess-nsh-bgp-control-plane-04.txt

Tony Przygienda <> Fri, 17 February 2017 00:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF91512941D for <>; Thu, 16 Feb 2017 16:16:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.775
X-Spam-Level: **
X-Spam-Status: No, score=2.775 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, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=3.795, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OvJ-YIOQgDgF for <>; Thu, 16 Feb 2017 16:16:39 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EC8981293EC for <>; Thu, 16 Feb 2017 16:16:38 -0800 (PST)
Received: by with SMTP id i10so21655463wrb.0 for <>; Thu, 16 Feb 2017 16:16:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:to:cc:subject:mime-version:date:reply-to:message-id :in-reply-to:references; bh=dzhhCmXabZhEJ8bo9vA0+tg5hysecA+kHgFhiLufTPw=; b=S0oZl9KzTkA0l/YnmeWhx+v5T+8zB4Kvcq/Nf0S7i+N1QYi9czrbzg752Aqg6NMWl4 0IeL7ve1qlSZh8mNY7MnFjmjA+v9QjuNRyfd8gjO+MgK66nN0LSeMtkFowv+z3mH12Ef TaMfyEs3mkxsrqAO1DzOGo9aFdPhFcrQsRGeJ3JIhTgfi7t3ULmC8EAMDjEsn/9U31DG Ie0tPqvbNkiAuyAM0nPPN2brXMa0X8WGEebke8nZQjYzXZXvfUr2qxoPF17Z4Gn3fW/L HPWQ/rmn+Ddw8ua1nmGaVdXfrBTHjAckh/nx5dsHAd9B4pGPc8rA38TlOgZXlYk08mgX C1jA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:cc:subject:mime-version:date:reply-to :message-id:in-reply-to:references; bh=dzhhCmXabZhEJ8bo9vA0+tg5hysecA+kHgFhiLufTPw=; b=MFUQ+rswcMd0rtd9QP0jMLWDupnV6OSru+HFlEZNvnodAHIzaQ4G594LRC9NboGW7Q EWTAxzr8PkVhODHMHqqaYQt/ofQ1N25CDSviXgpVXPKlVdzuiyhMFurAD9NPOmqNlSJ/ u2Ecko8Ps160YMXnh65E5ZngrCsSq7ahmLVcMGmejWf0xelILF9esiVyTk2dOlIkCA4i NZbl7otOtcivV/IMDOs8v3ogigp6T4OhFq7KVwQjreKXWelkNj+1lXQxLiaxuIQyCiD5 lYtBJi39XxaFMueJeXY12mefpUiaXssK1kQki8ILOZSO+KatwPoG57lUcZt0Y8wXIYdD +ZkQ==
X-Gm-Message-State: AMke39n55sGVm53y6UOrXziQ95KLM++b+7bC5hnl4Vl7A8YAx3SllmULF8AEoroTkWoY9A==
X-Received: by with SMTP id n51mr4156614wrn.158.1487290597505; Thu, 16 Feb 2017 16:16:37 -0800 (PST)
Received: from ( []) by with ESMTPSA id g11sm10847045wrb.63.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 16:16:35 -0800 (PST)
From: Tony Przygienda <>
To: Adrian Farrel <>
MIME-Version: 1.0
X-Mailer: Mailer 1.0
X-Originating-IP: []
Date: Fri, 17 Feb 2017 03:16:34 +0300
X-Letter-Fingerprint: Hi3K8Fbd1zgY7RjVljmHFedtsOENyySx
X-Priority: 3 (Normal)
Message-ID: <>
Content-Type: multipart/alternative; boundary="--ALT--iM8uhhfa1487290594"
X-E1FCDC63: A328DCBFD0D48ACA2DCFE6D27BA78028074A40F52AF1438D
X-Mras: OK
X-Spam: undefined
In-Reply-To: <0a2c01d2889b$2eda90f0$8c8fb2d0$>
References: <0a2c01d2889b$2eda90f0$8c8fb2d0$>
Archived-At: <>
Cc: idr wg <>
Subject: Re: [Idr] IDR heads up on BESS draft: BGP for SFC: draft-mackie-bess-nsh-bgp-control-plane-04.txt
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Tony Przygienda <>
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Feb 2017 00:16:41 -0000

Discounted for same affiliation with the authors 😏 I do think personally it's a symmetrical, quite elegant and low risk/effort draft given how successful equivalent BGP "low level network service access point" synchronization proposals were over last years ...

Sent from myMail for iOS

Thursday, February 16, 2017, 13:25 -0800 from Adrian Farrel  <>:
>Hi IDR,
>We have an I-D in BESS (also discussed in SFC) that proposes to use BGP as a
>control plane for and SFC (overlay) network.
>You can best grasp the proposed extensions to BGP by looking at the I-D. We
>think the extensions are natural and relatively small, by YMMV :-)
>Completely understanding what we are planning may be hard without some
>background in service function chaining, but from 30,000 ft...
>An SFC network is an overlay network.
>Service Function Forwarders (SFFs) are connected by tunnels over one or more
>underlay networks.
>SFFs provide access to Service Function Instances (SFIs)
>SFIs are strung together in an ordered sequence called a Service Function Path
>(SFP) [an instance of a Service Function Chain (SFC)]
>It used to be that service functions were installed as physical bumps in the
>wire, but now they may be remote and virtualized.
>Packets that need to be acted on by a series of service functions (an SFC) are
>classified by a Classifier and assigned to an SFP.
>The packets are marked (with an additional encapsulation header) and passed from
>SFF to SFF for delivery to the SFIs.
>Our approach uses BGP so that:
>- SFFs can advertise which SFIs they provide access to so that a controller can
>build SFPs
>- a controller to advertise the various SFPs so that SFFs can work out how to
>   packets to the right SFIs, and how to route packets to the correct next SFF
>- a controller to instruct a Classifier on how to select the right SFP
>We also help the SFF know what tunnel to use to reach the next SFF, and what SFC
>encapsulation to use on each hop.
>For more details, read the draft :-)
>Discussions should probably be on the BESS list, but we will probably also spot
>them if they happen here.
>Idr mailing list