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" <tonysi...@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 < adr...@olddog.co.uk>: 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 i...@ietf.org <https://e-aj.my.com/compose?To=i...@ietf.org> https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list i...@ietf.org https://www.ietf.org/mailman/listinfo/idr
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
