| < draft-penno-sfc-yang-12.txt | draft-penno-sfc-yang-13.txt > | |||
|---|---|---|---|---|
| SFC Netmod R. Penno | SFC Netmod R. Penno | |||
| Internet-Draft P. Quinn | Internet-Draft P. Quinn | |||
| Intended status: Standards Track Cisco Systems | Intended status: Standards Track Cisco Systems | |||
| Expires: September 3, 2015 D. Zhou | Expires: September 3, 2015 D. Zhou | |||
| J. Li | J. Li | |||
| Intel Corporation | Intel Corporation | |||
| March 02, 2015 | March 02, 2015 | |||
| Yang Data Model for Service Function Chaining | Yang Data Model for Service Function Chaining | |||
| draft-penno-sfc-yang-12 | draft-penno-sfc-yang-13 | |||
| Abstract | Abstract | |||
| This document defines a YANG data model that can be used to configure | This document defines a YANG data model that can be used to configure | |||
| and manage Service Function Chains. | and manage Service Function Chains. | |||
| Requirements Language | Requirements Language | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| skipping to change at page 3, line 32 ¶ | skipping to change at page 3, line 32 ¶ | |||
| and manage Service Function Chains | and manage Service Function Chains | |||
| 2. Definitions and Acronyms | 2. Definitions and Acronyms | |||
| The reader should be familiar with the terms contained in | The reader should be familiar with the terms contained in | |||
| [I-D.ietf-sfc-architecture], [I-D.ietf-sfc-problem-statement] | [I-D.ietf-sfc-architecture], [I-D.ietf-sfc-problem-statement] | |||
| ,[I-D.ietf-sfc-architecture] and [I-D.quinn-vxlan-gpe] | ,[I-D.ietf-sfc-architecture] and [I-D.quinn-vxlan-gpe] | |||
| 3. Understanding SFC Yang Models | 3. Understanding SFC Yang Models | |||
| There are three main models in SFC: service-function(SF) and service- | There are two main models in SFC: service-function (SF) and service- | |||
| function-forwarder (SFF). Most other models are used or derived from | function-forwarder (SFF). Most other models are used or derived from | |||
| those models. SF describes a service function like firewall, napt44, | those models. SF describes a service function like firewall, napt44, | |||
| dpi, http-proxy, etc. SFF describes a forwarding element that moves | dpi, http-proxy, etc. SFF describes a forwarding element that moves | |||
| packets along a service path. A SFF to function only needs to be | packets along a service path. A SFF to function only needs to be | |||
| able to associate a Service Path ID and SI to a next hop data plane | able to associate a Service Path ID and SI to a next hop data plane | |||
| locator. | locator. | |||
| The service-locator model provides a centralized place to register | The service-locator model provides a centralized place to register | |||
| transport and endpoints used with SFFs and SFs. This allows reuse | transport and endpoints used with SFFs and SFs. This allows reuse | |||
| across a large number of other models since in networking usually | across a large number of other models since in networking usually | |||
| data plane locators are widely used. Some examples of transport | data plane locators are widely used. Some examples of transport | |||
| types are GRE, VXLAN-GPE and the data plane locator are IP:port, | types are GRE, VXLAN-GPE and the data plane locator are IP:port, | |||
| VLAN-ID and MPLS Label. This model is imported by SFF, SF and | VLAN-ID and MPLS Label. This model is imported by SFF, SF and | |||
| Rendered Service Path (RSP) models. | Rendered Service Path (RSP) models. | |||
| Service Function Type model serves as a registry for SF types. The | Service Function Type model serves as a registry for SF types. The | |||
| model can be easily extended by anyone looking to define their own | model can be easily extended by anyone looking to define their own | |||
| service type. This model is imported by SF and SFC. Since a SFC is | service type. This model is imported by SF and Service Function | |||
| an abstract order of service function types, having a registry of | Chain (SFC). Since a SFC is an abstract order of service function | |||
| types is important. Furthermore, instantiating a SFP and RSP from a | types, having a registry of types is important. Furthermore, when we | |||
| SFC we need to choose the actual SFs that will be traversed by the | instantiate a SFP and RSP from a SFC we need to choose the actual SFs | |||
| packets and this requires us to know the types associated with a | that will be traversed by the packets and this requires us to know | |||
| Service Function. | the type associated with a Service Function. | |||
| A service function path is an intermediate step between SFC and RSP. | A service function path (SFP) is an intermediate step between SFC and | |||
| It allows the user to provide input or constraints into the | RSP. It allows the user to provide input or constraints into the | |||
| construction of a RSP. This input ranges from nothing to specifying | construction of a RSP. This input ranges from nothing to specifying | |||
| the entire path. During RSP construction, the controller examines | the entire path. During RSP construction, the controller examines | |||
| the SFP and 'fill in the blanks'. | the SFP and 'fill in the blanks'. | |||
| One of the most important configuration aspects of a SF is the data | One of the most important configuration aspects of a SF is the data | |||
| plane locators. A SF data plane locators indicates how the SF can be | plane locators. A SF's data plane locators indicates how the SF can | |||
| reached. A SF can have multiple data plane locators of different | be reached. A SF can have multiple data plane locators of different | |||
| types as specified in the service locator model. | transport and types as specified in the service locator model. | |||
| A SFF has also can have multiple data plane locators that indicated | A SFF has also can have multiple data plane locators that indicate | |||
| how it can be reached. It is very important when constructing a RSP | how it can be reached. It is very important when constructing a RSP | |||
| to pick SFFs that have data plane locators of the same transport and | to pick SFFs that have data plane locators of the same transport and | |||
| type so that the path works. A SFF has an additional very important | type so that the path works. A SFF has an additional very important | |||
| configuration container, the service function dictionary. The | configuration container, the service function dictionary. The | |||
| service function dictionary stores the SFF's view of the Service | service function dictionary stores the SFF's view of the Service | |||
| Functions. It contains all SFs and their data plane locators. | Functions. It contains all SFs and their data plane locators. | |||
| Therefore the Service Function data plane locators and the SFF | Therefore the Service Function data plane locators and the SFF | |||
| service function dictionary constitute two pieces of a puzzle. If | service function dictionary constitute two pieces of a puzzle. If | |||
| they fit, it means they can be used in a path, otherwise they can | they fit, it means they can be used in a path, otherwise they can | |||
| End of changes. 6 change blocks. | ||||
| 14 lines changed or deleted | 14 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||