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

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 16 Feb 2017 21:25:18 -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

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 17 Feb 2017 03:16:34 +0300

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  <[email-masked]>:
>_______________________________________________
>Idr mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/idr

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 17 Feb 2017 01:55:07 +0100

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" <[email-masked]> 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 <
[email-masked]>:

Hi IDR,

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.

Discussions should probably be on the BESS list, but we will probably also
spot
them if they happen here.

Thanks,
Adrian

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