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

"Adrian Farrel" <adrian@olddog.co.uk> Thu, 16 February 2017 21:25 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA9B1296E0 for <idr@ietfa.amsl.com>; Thu, 16 Feb 2017 13:25:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
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 3namfkL8pHZi for <idr@ietfa.amsl.com>; Thu, 16 Feb 2017 13:25:27 -0800 (PST)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CC60129541 for <idr@ietf.org>; Thu, 16 Feb 2017 13:25:26 -0800 (PST)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1GLPOBI005907 for <idr@ietf.org>; Thu, 16 Feb 2017 21:25:24 GMT
Received: from 950129200 ([176.241.251.4]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1GLPJ8k005842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <idr@ietf.org>; Thu, 16 Feb 2017 21:25:23 GMT
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <idr@ietf.org>
Date: Thu, 16 Feb 2017 21:25:18 -0000
Message-ID: <0a2c01d2889b$2eda90f0$8c8fb2d0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdKImyrDnxgaHHXPTOi5LvYFNvdWug==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22890.002
X-TM-AS-Result: No--3.075-10.0-31-10
X-imss-scan-details: No--3.075-10.0-31-10
X-TMASE-MatchedRID: IczRV1NxQ4W77rpLLmM7AsWUKBjERoYTzJmqByfAaS0gbNDlPT+rW4N2 pMn0FcvGXIsFfI8Rrp6xdNvdS/WxrbWd3Qhj3xBVVU3yVpaj3QxMkOX0UoduufEf3vDTPPt1eqO qRRe6+9GakvRUUhDHxLE3s3jsznvfMtCMcfANeKYSaNhZLec7QFPniy82Q6c7H46Jyk9t8h0l3W kwfnyDsS3PP/lRNSyBaeqGQCNgxozR4aWLy95VW6t9n66zJ4RI9NYqzb2oOWsPpGoR1th3non/i oA/OBIdm0VAoQhcJHIu+FzXyTad7TZJ9FayTxRpq1ZJZ2z+SbbJ5SXtoJPLyApcq1+LTpsUo8WM kQWv6iV95l0nVeyiuDrm2CwlZwVRrFldG3ZH+DmctPRRi1pLaISpzlM+e8DN8wrJ6gure4VP9V9 SpUxtCK9T2b/eJnmJlo3Iojv8AKj6/zAH+bBXQx9avEsi0xwEMps6DAw1eWkogMKdauoOlfR5gL DNdb9LuOZoyiCGGN8YgmnfWgSln5vaf0QvfUyeC8XKjsVbJjU=
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Qz60CBkt2NEXauRiZ1NTYw3fNew>
Subject: [Idr] IDR heads up on BESS draft: BGP for SFC: draft-mackie-bess-nsh-bgp-control-plane-04.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Feb 2017 21:25:32 -0000

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
deliver 
   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.

Thanks,
Adrian