draft-ietf-bess-service-chaining-02.txt   draft-ietf-bess-service-chaining-03.txt 
BGP Enabled Services (bess) R. Fernando BGP Enabled Services (bess) R. Fernando
INTERNET-DRAFT Cisco INTERNET-DRAFT Cisco
Intended status: Standards Track S. Mackie Intended status: Standards Track S. Mackie
Expires: May 4, 2017 Juniper Expires: January 7, 2018 Juniper
D. Rao D. Rao
Cisco Cisco
B. Rijsman B. Rijsman
Juniper Juniper
M. Napierala M. Napierala
AT&T AT&T
T. Morin T. Morin
Orange Orange
October 31, 2016
July 3, 2017
Service Chaining using Virtual Networks with BGP VPNs Service Chaining using Virtual Networks with BGP VPNs
draft-ietf-bess-service-chaining-02 draft-ietf-bess-service-chaining-03
Abstract Abstract
This document describes how service function chains (SFC) can be This document describes how service function chains (SFC) can be
applied to traffic flows using routing in a virtual (overlay) network applied to traffic flows using routing in a virtual (overlay) network
to steer traffic between service nodes. Chains can include services to steer traffic between service nodes. Chains can include services
running in routers, on physical appliances or in virtual machines. running in routers, on physical appliances or in virtual machines.
Service chains have applicability at the subscriber edge, business Service chains have applicability at the subscriber edge, business
edge and in multi-tenant datacenters. The routing function into SFCs edge and in multi-tenant datacenters. The routing function into SFCs
and between service functions within an SFC can be performed by and between service functions within an SFC can be performed by
skipping to change at page 6, line 44 skipping to change at page 6, line 44
branching within a service function chain. branching within a service function chain.
Virtual Network: A logical overlay network built using virtual links Virtual Network: A logical overlay network built using virtual links
or packet encapsulation, over an existing network (the underlay). or packet encapsulation, over an existing network (the underlay).
Service Function Chain (SFC): A service function chain defines an Service Function Chain (SFC): A service function chain defines an
ordered set of service functions that must be applied to packets ordered set of service functions that must be applied to packets
and/or frames selected as a result of classification. An SFC may be and/or frames selected as a result of classification. An SFC may be
either a linear chain or a complex service graph with multiple either a linear chain or a complex service graph with multiple
branches. The term 'Service Chain' is often used in place of branches. The term 'Service Chain' is often used in place of
'Service Function Chain'.
SFC Set: The pair of SFCs through which the forward and reverse SFC Set: The pair of SFCs through which the forward and reverse
directions of a given classified flow will pass. directions of a given classified flow will pass.
Service Function (SF): A logical function that is applied to Service Function (SF): A logical function that is applied to
packets. A service function can act at the network layer or other packets. A service function can act at the network layer or other
OSI layers. A service function can be embedded in one or more OSI layers. A service function can be embedded in one or more
physical network elements, or can be implemented in one or more physical network elements, or can be implemented in one or more
software instances running on physical or virtual hosts. One or software instances running on physical or virtual hosts. One or
multiple service functions can be embedded in the same network multiple service functions can be embedded in the same network
skipping to change at page 14, line 49 skipping to change at page 14, line 49
When more than one instance of an SF is running on a hypervisor, they When more than one instance of an SF is running on a hypervisor, they
can be connected to the same VRF for scale out of an SF within an can be connected to the same VRF for scale out of an SF within an
SFC. SFC.
The routing mechanisms in the VRFs into and between service function The routing mechanisms in the VRFs into and between service function
instances, and the encapsulation tunneling between routing systems instances, and the encapsulation tunneling between routing systems
are identical in the physical and virtual implementations of SFCs and are identical in the physical and virtual implementations of SFCs and
routing systems described in this document. Physical and virtual routing systems described in this document. Physical and virtual
service functions can be mixed as needed with different combinations service functions can be mixed as needed with different combinations
of physical and virtual routing systems, within a single service
chain. chain.
The SF instances are attached to the routing systems via physical, The SF instances are attached to the routing systems via physical,
virtual or logical (e.g, 802.1q) interfaces, and are assumed to virtual or logical (e.g, 802.1q) interfaces, and are assumed to
perform basic L3 or L2 forwarding. perform basic L3 or L2 forwarding.
A single SF instance can be part of multiple service chains. In this A single SF instance can be part of multiple service chains. In this
case, the SF instance will have dedicated interfaces (typically case, the SF instance will have dedicated interfaces (typically
logical) and forwarding contexts associated with each service chain. logical) and forwarding contexts associated with each service chain.
skipping to change at page 21, line 42 skipping to change at page 21, line 42
sections - one linking the entry and exit VRFs and the other sections - one linking the entry and exit VRFs and the other
including the intermediate systems. For instance, this may be including the intermediate systems. For instance, this may be
achieved by using two different Service-topology-RTs in the second achieved by using two different Service-topology-RTs in the second
method. method.
2.8.2 Using a Default Route and a Large Prefix 2.8.2 Using a Default Route and a Large Prefix
In the configuration methods described above, the network prefixes In the configuration methods described above, the network prefixes
for each network (Network-A and Network-B in the example above) for each network (Network-A and Network-B in the example above)
connected to the SFC are used in the routes that direct traffic connected to the SFC are used in the routes that direct traffic
through the SFC. This creates an operational linkage between the
implementation of the SFC and the insertion of the SFC into a implementation of the SFC and the insertion of the SFC into a
network. network.
For instance, subscriber network prefixes will normally be segmented For instance, subscriber network prefixes will normally be segmented
across subscriber attachment points such as broadband or mobile across subscriber attachment points such as broadband or mobile
gateways. This means that each SFC would have to be configured with gateways. This means that each SFC would have to be configured with
the subscriber network prefixes whose traffic it is handling. the subscriber network prefixes whose traffic it is handling.
In a variation of the SFC configuration method described above, the In a variation of the SFC configuration method described above, the
prefixes used in each direction can be such that they include all prefixes used in each direction can be such that they include all
skipping to change at page 29, line 45 skipping to change at page 29, line 45
forward/reverse paths for flows and minimal disruption when SF forward/reverse paths for flows and minimal disruption when SF
instances are added to or removed from a set. Two techniques that can instances are added to or removed from a set. Two techniques that can
be employed are described in the following sections. be employed are described in the following sections.
3.4.2 Modified ECMP with Consistent Hash 3.4.2 Modified ECMP with Consistent Hash
Symmetric forwarding into each side of an SF instance set can be Symmetric forwarding into each side of an SF instance set can be
achieved with a small modification to ECMP if the packet headers are achieved with a small modification to ECMP if the packet headers are
preserved after passing through the SF instance set and assuming that preserved after passing through the SF instance set and assuming that
the same hash function, same hash salt and same ordering association the same hash function, same hash salt and same ordering association
of hash buckets to ECMP routes is used in both of hash buckets to ECMP routes is used in both directions. Each packet's
5-tuple data is used to calculate which hash bucket, and therefore
hash bucket, and therefore which service instance, that the packet which service instance, that the packet will be sent to, but the source
will be sent to, but the source and destination IP address and port and destination IP address and port information are swapped in the
information are swapped in the calculation in the reverse direction. calculation in the reverse direction. This method only requires that the
This method only requires that the list of available service function list of available service function instances is consistently maintained
instances is consistently maintained in load balance tables in all in load balance tables in all the routing systems rather than maintaining
the routing systems rather than maintaining flow tables. This flow tables. This requirement can be met by the use of a distinct VPN
requirement can be met by the use of a distinct VPN route for each route for each instance.
instance.
In the SFC architecture described in this document, when SF instances In the SFC architecture described in this document, when SF instances
are added or removed, the controller is required to install (or are added or removed, the controller is required to install (or
remove) routes to the SF instances. The controller could configure remove) routes to the SF instances. The controller could configure
the load balancing function in VRFs that connect to each added (or the load balancing function in VRFs that connect to each added (or
removed) SF instance as part of the same network transaction as route removed) SF instance as part of the same network transaction as route
updates to ensure that the load balancer configuration is updates to ensure that the load balancer configuration is
synchronized with the set of SF instances. synchronized with the set of SF instances.
The consistent ordering among ECMP routes in the routing systems The consistent ordering among ECMP routes in the routing systems
skipping to change at page 31, line 43 skipping to change at page 31, line 43
the same SF instances, and that if the number of ECMP routes changes the same SF instances, and that if the number of ECMP routes changes
when SF instances are added or removed, all existing flows will when SF instances are added or removed, all existing flows will
continue to flow through the same SF instances, but new flows will continue to flow through the same SF instances, but new flows will
use the new ECMP hash. The only flows affected will be those that use the new ECMP hash. The only flows affected will be those that
were passing through an SF instance that was removed, and those will were passing through an SF instance that was removed, and those will
be spread among the remaining SF instances using the updated ECMP be spread among the remaining SF instances using the updated ECMP
hash. hash.
If the consistent hash algorithm is used in both directions, then If the consistent hash algorithm is used in both directions, then
only the forwarding flow entries would be required, and would be only the forwarding flow entries would be required, and would be
built independently in each direction. If distinct VPN routes with
next-hop forwarding labels are used, then only the flow table in step next-hop forwarding labels are used, then only the flow table in step
3 is sufficient to provide flow stickiness. 3 is sufficient to provide flow stickiness.
3.4.4 Dealing with different hash algorithms in an SFC 3.4.4 Dealing with different hash algorithms in an SFC
In some cases, there will be two or more hash algorithms in In some cases, there will be two or more hash algorithms in
forwarders along an SFC. E.g. when a physical router is at the entry forwarders along an SFC. E.g. when a physical router is at the entry
and exit of the chain, and virtual forwarders are used within the and exit of the chain, and virtual forwarders are used within the
chain. Forward and reverse flows will mostly not pass through the chain. Forward and reverse flows will mostly not pass through the
same SF instances of the first SF, and the SFC will not operate as same SF instances of the first SF, and the SFC will not operate as
skipping to change at page 33, line 48 skipping to change at page 33, line 48
destination network prefixes and the modified method of setting destination network prefixes and the modified method of setting
prefixes, described in Section 2.8.2 can be employed. Also, the exit prefixes, described in Section 2.8.2 can be employed. Also, the exit
VRF for each SFC does not peer with a gateway or proxy node in the VRF for each SFC does not peer with a gateway or proxy node in the
destination network and packets are forwarded using IP lookup in the destination network and packets are forwarded using IP lookup in the
main routing table or in a VRF that the exit traffic from the SFCs is main routing table or in a VRF that the exit traffic from the SFCs is
directed into (shown as X in the diagram). A flow table may be directed into (shown as X in the diagram). A flow table may be
required to ensure that reverse traffic is sent into the correct SFC. required to ensure that reverse traffic is sent into the correct SFC.
An alternative would be where the classifier is itself a distributed, An alternative would be where the classifier is itself a distributed,
virtualized service function, but with multiple egress interfaces. In virtualized service function, but with multiple egress interfaces. In
that case, each virtual classifier instance could be entry VRF would that case, each virtual classifier instance could be attached to a set
of VRFs that connect to different SFCs. Each chain entry VRF would
load balance across the first SF instance set in its SFC. The reverse load balance across the first SF instance set in its SFC. The reverse
flow table mechanism described in Section 3.4.3 could be employed to flow table mechanism described in Section 3.4.3 could be employed to
ensure that flows return to the originating classifier instance which ensure that flows return to the originating classifier instance which
may maintain subscriber context and perform charging and accounting. may maintain subscriber context and perform charging and accounting.
5 External Domain Co-ordination 5 External Domain Co-ordination
It is likely that SFCs will be managed as a separate administrative It is likely that SFCs will be managed as a separate administrative
domain from the networks that they receive traffic from, and send domain from the networks that they receive traffic from, and send
traffic to. If the connected networks use BGP for route distribution, traffic to. If the connected networks use BGP for route distribution,
skipping to change at page 35, line 39 skipping to change at page 35, line 39
8 Coordination Between SF Instances and Controller using BGP 8 Coordination Between SF Instances and Controller using BGP
In many cases, the configuration of SF instance determines its In many cases, the configuration of SF instance determines its
network behavior. E.g. when NAT pools are set up, or when an SSL network behavior. E.g. when NAT pools are set up, or when an SSL
gateway is configured with a set of enterprise IP addresses to use. gateway is configured with a set of enterprise IP addresses to use.
In these cases, the addresses that will be used by the SFs need to be In these cases, the addresses that will be used by the SFs need to be
known in the networks connecting to them in order that traffic can be known in the networks connecting to them in order that traffic can be
properly routed. When SFCs are involved, this means that the properly routed. When SFCs are involved, this means that the
controller has to be notified when such configuration changes are controller has to be notified when such configuration changes are
made in SF instances. Sometimes, the changes will be made by end- made in SF instances. Sometimes, the changes will be made by end-
customers and it is desirable the controller adjust the SFC routing
configuration automatically when the change is made, and without configuration automatically when the change is made, and without
customers needing to notify the service provider via a portal, for customers needing to notify the service provider via a portal, for
instance, or requiring development of integration modules linking the instance, or requiring development of integration modules linking the
SF instances and the controller. SF instances and the controller.
One option for automatic notification for SFs that support BGP is for One option for automatic notification for SFs that support BGP is for
the connected forwarding system (physical or virtual SFF) to also the connected forwarding system (physical or virtual SFF) to also
support BGP, and for SF instances to be configured to peer with the support BGP, and for SF instances to be configured to peer with the
SFF. When changes are made to the configuration of a SF instance, SFF. When changes are made to the configuration of a SF instance,
that for example, the SF will accept packets from a particular that for example, the SF will accept packets from a particular
skipping to change at page 38, line 17 skipping to change at page 38, line 17
The architecture for service function chains described in this The architecture for service function chains described in this
document uses virtual networks implemented as overlays in order to document uses virtual networks implemented as overlays in order to
create service function chains. The virtual networks use standards- create service function chains. The virtual networks use standards-
based encapsulation tunneling, such as MPLS over GRE/UDP or VXLAN, to based encapsulation tunneling, such as MPLS over GRE/UDP or VXLAN, to
transport packets into an SFC and between service function instances transport packets into an SFC and between service function instances
without routing in the user address space. Two methods of installing without routing in the user address space. Two methods of installing
routes to form service chains are described. routes to form service chains are described.
In environments with physical routers, a controller may operate in In environments with physical routers, a controller may operate in
tandem with existing BGP route reflectors, and would contain the SFC tandem with existing BGP route reflectors, and would contain the SFC
toology model, and the ability to install the local static interface topology model, and the ability to install the local static interface
routes to SF instances. In a virtualized environment, the controller routes to SF instances. In a virtualized environment, the controller
can emulate route refection internally and simply install required can emulate route refection internally and simply install required
routes directly without advertisements occurring. routes directly without advertisements occurring.
11 Security Considerations 11 Security Considerations
The security considerations for SFCs are broadly similar to those The security considerations for SFCs are broadly similar to those
concerning the data, control and management planes of any device concerning the data, control and management planes of any device
placed in a network. Details are out of scope for this document. placed in a network. Details are out of scope for this document.
 End of changes. 11 change blocks. 
15 lines changed or deleted 21 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/