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

Robert Raszuk <robert@raszuk.net> Fri, 17 February 2017 00:55 UTC

Return-Path: <rraszuk@gmail.com>
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 042211296E7; Thu, 16 Feb 2017 16:55:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.596
X-Spam-Level:
X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 7iGMxsmo6WOY; Thu, 16 Feb 2017 16:55:08 -0800 (PST)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 7A64512944F; Thu, 16 Feb 2017 16:55:08 -0800 (PST)
Received: by mail-qk0-x229.google.com with SMTP id s186so32198061qkb.1; Thu, 16 Feb 2017 16:55:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=c3z4cwIzURhxML3Aif/BHxSrHFTVrSUXjVvqW55wy2E=; b=YRXBvk6vBBcSEbsq8HF7G7rQAYgivMlFig5Ii9r3aGnZm/EOMXQKTj9hA4TeFRrA4O mBzxOoyY9dsCAjBo4wPyP0LRUZhRtiUcmhg/NzR02nvv4k3w2/1b09RVK9FnoIuJACsc cJjiVN813iiVvXCUd7UxTqYxoGNjFETneGpltj/D3b/b+Mj24FU3hhUclK2bryjsQkjq BwvqBUiL8slMOSJqxQda2RVIhrV9BkqYAApO8c7OPEw7ip+n7Le8b/b6D5Nh11UNgfCb 79A1q6K6EwfvDCqXPAaX0rvB4PiUteNzZ+4x93dNdqNzDWPDyrviNWeK+JVLpJKP+8q9 jYQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=c3z4cwIzURhxML3Aif/BHxSrHFTVrSUXjVvqW55wy2E=; b=XctKu3immc3Mmg1LBpXEq8skkd0B5XKEdfaj0u4v6d7RNV+Mp8COUAdY3t5wEm2oLS BAylZjiE5Wbye2UIgDBs8AGosdtzYktrUoC29KEv5d4jcTa1J75EK34pc3EeL/GkstZT wTNnO444pOr//LC+gyM5BNWsd5kTGoHYq6ncc8uMxCrTTi94LXsqxMsqKFLTx5iNdOlw 9iPkSaRrQbk++HOVOMwn7482h3tmNuOTwYZiPzJ+XQkY/0U1LVoHYoQft+T+Oq0yZfNg IQJ6Y5fUlxp97yiwaHIRNARYQQsqaLoYCX/J0KX3MdEhtQI0e/rVO8S5Yc9YknEe6As4 na1g==
X-Gm-Message-State: AMke39niciYWB2lQujVseHlg+OrxvNIGdLXZKQs3Royie+2xPEGN8h+WiwFuaZRKAXnlkjBkgSxSrzDTM5yvPg==
X-Received: by 10.55.192.93 with SMTP id o90mr4914410qki.18.1487292907607; Thu, 16 Feb 2017 16:55:07 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.140.28.69 with HTTP; Thu, 16 Feb 2017 16:55:07 -0800 (PST)
Received: by 10.140.28.69 with HTTP; Thu, 16 Feb 2017 16:55:07 -0800 (PST)
In-Reply-To: <1487290594.4104319@f4.my.com>
References: <0a2c01d2889b$2eda90f0$8c8fb2d0$@olddog.co.uk> <1487290594.4104319@f4.my.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 17 Feb 2017 01:55:07 +0100
X-Google-Sender-Auth: xZ8cBrFCyp5DHPrUNISN6wDeAis
Message-ID: <CA+b+ERkZiR_wk4Aw8nCehwAPp+ZAoWRGAb1wZ+VxzjvdUfQYGA@mail.gmail.com>
To: Tony Przygienda <tonysietf@gmail.com>
Content-Type: multipart/alternative; boundary=001a114990b26f61200548af5dd9
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/e9aueba9rWCeqsNW0l7SrXRAxs8>
Cc: bess@ietf.org, idr wg <idr@ietf.org>
Subject: Re: [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
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: Fri, 17 Feb 2017 00:55:11 -0000

Hi,

Using BGP as control plane for arbitrary service topology creation is by
all means a good thing.

That is why in 2013 Keyur and myself have posted proposal describing it to
IETF in form of BGP Vector Routing:

https://tools.ietf.org/html/draft-patel-raszuk-bgp-vector-routing-00

I leave it to the audience of bess and idr working groups to jugde which of
two proposals is more elegant and low risk and effort.

Cheers,
R.


On Feb 16, 2017 7:17 PM, "Tony Przygienda" <tonysietf@gmail.com> wrote:

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 <
adrian@olddog.co.uk>gt;:

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

_______________________________________________
Idr mailing list
Idr@ietf.org <https://e-aj.my.com/compose?To=Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr


_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr