draft-ietf-sfc-nsh-10.txt   draft-ietf-sfc-nsh-11.txt 
Service Function Chaining P. Quinn, Ed. Service Function Chaining P. Quinn, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track U. Elzur, Ed. Intended status: Standards Track U. Elzur, Ed.
Expires: March 24, 2017 Intel Expires: August 16, 2017 Intel
September 20, 2016 February 12, 2017
Network Service Header Network Service Header
draft-ietf-sfc-nsh-10.txt draft-ietf-sfc-nsh-11.txt
Abstract Abstract
This document describes a Network Service Header (NSH) inserted onto This document describes a Network Service Header (NSH) inserted onto
packets or frames to realize service function paths. NSH also packets or frames to realize service function paths. NSH also
provides a mechanism for metadata exchange along the instantiated provides a mechanism for metadata exchange along the instantiated
service path. NSH is the SFC encapsulation required to support the service path. NSH is the SFC encapsulation required to support the
Service Function Chaining (SFC) Architecture (defined in RFC7665). Service Function Chaining (SFC) Architecture (defined in RFC7665).
1. Requirements Language 1. Requirements Language
skipping to change at page 2, line 26 skipping to change at page 2, line 26
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 24, 2017. This Internet-Draft will expire on August 16, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 6, line 11 skipping to change at page 6, line 11
1. Topological Independence: Service forwarding occurs within the 1. Topological Independence: Service forwarding occurs within the
service plane, the underlying network topology does not require service plane, the underlying network topology does not require
modification. NSH provides an identifier used to select the modification. NSH provides an identifier used to select the
network overlay for network forwarding. network overlay for network forwarding.
2. Service Chaining: NSH enables service chaining per [RFC7665]. 2. Service Chaining: NSH enables service chaining per [RFC7665].
NSH contains path identification information needed to realize a NSH contains path identification information needed to realize a
service path. Furthermore, NSH provides the ability to monitor service path. Furthermore, NSH provides the ability to monitor
and troubleshoot a service chain, end-to-end via service-specific and troubleshoot a service chain, end-to-end via service-specific
OAM messages. The NSH fields can be used by administrators (via, OAM messages. The NSH fields can be used by administrators (via,
for example a traffic analyser) to verify (account, ensure for example, a traffic analyzer) to verify (account, ensure
correct chaining, provide reports, etc.) the path specifics of correct chaining, provide reports, etc.) the path specifics of
packets being forwarded along a service path. packets being forwarded along a service path.
3. NSH provides a mechanism to carry shared metadata between 3. NSH provides a mechanism to carry shared metadata between
participating entities and service functions. The semantics of participating entities and service functions. The semantics of
the shared metadata is communicated via a control plane, which is the shared metadata is communicated via a control plane, which is
outside the scope of this document, to participating nodes. outside the scope of this document, to participating nodes.
[SFC-CP] provides an example of such in section 3.3. Examples of [SFC-CP] provides an example of such in section 3.3. Examples of
metadata include classification information used for policy metadata include classification information used for policy
enforcement and network context for forwarding post service enforcement and network context for forwarding post service
skipping to change at page 10, line 23 skipping to change at page 10, line 23
Service Index (SI): 8 bits Service Index (SI): 8 bits
Figure 3: NSH Service Path Header Figure 3: NSH Service Path Header
Service Path Identifier (SPI): identifies a service path. Service Path Identifier (SPI): identifies a service path.
Participating nodes MUST use this identifier for Service Function Participating nodes MUST use this identifier for Service Function
Path selection. The initial classifier MUST set the appropriate SPI Path selection. The initial classifier MUST set the appropriate SPI
for a given classification result. for a given classification result.
Service Index (SI): provides location within the SFP. The initial Service Index (SI): provides location within the SFP. The initial
classifier MUST set the appropriate SI value for a given classifier for a given SFP SHOULD set the SI to 255, however the
classification result. The initial SI value SHOULD default to 255. control plane MAY configure the initial value of SI as appropriate
However, the classifier MUST allow configuration of other SI values. (i.e. taking into account the length of the service function path).
Service Index MUST be decremented by Service Functions or by SFC Service Index MUST be decremented by Service Functions or by SFC
Proxy nodes after performing required services and the new Proxy nodes after performing required services and the new
decremented SI value MUST be used in the egress NSH packet. The decremented SI value MUST be used in the egress NSH packet. The
initial Classifier MUST send the packet to the first SFF in the initial Classifier MUST send the packet to the first SFF in the
identified SFP for forwarding along an SFP. If re-classification identified SFP for forwarding along an SFP. If re-classification
occurs, and that re-classification results in a new SPI, the occurs, and that re-classification results in a new SPI, the
(re)classifier is, in effect, the initial classifier for the (re)classifier is, in effect, the initial classifier for the
resultant SPI. resultant SPI.
SI SHOULD be used in conjunction with SPI for SFP selection and, SI SHOULD be used in conjunction with Service Path Identifier for
consequently, determining the next SFF/SF in the path. Service Index Service Function Path Selection and for determining the next SFF/SF
(SI) is also valuable when troubleshooting/ reporting service paths. in the path. Service Index (SI) is also valuable when
When an SPI and SI do not correspond to a valid next hop in a SFP, it troubleshooting/ reporting service paths. In addition to indicating
is an error and the SFF SHOULD generate an error/log message. The the location within a Service Function Path, SI can be used for
value zero for SI is not valid and indicates a broken SFC or service plane loop detection.
malfunctioning SF. In addition to indicating the location within a
Service Function Path, SI can be used for service plane loop
detection.
3.4. NSH MD Type 1 3.4. NSH MD Type 1
When the Base Header specifies MD Type = 0x1, four Context Headers, When the Base Header specifies MD Type = 0x1, four Context Headers,
4-byte each, MUST be added immediately following the Service Path 4-byte each, MUST be added immediately following the Service Path
Header, as per Figure 4. Context Headers that carry no metadata MUST Header, as per Figure 4. Context Headers that carry no metadata MUST
be set to zero. be set to zero.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|C|R|R|R|R|R|R| Length | MD type=0x1 | Next Protocol | |Ver|O|C|R|R|R|R|R|R| Length | MD type=0x1 | Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Identifer | Service Index | | Service Path Identifer | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fixed Length Context Header |
| Mandatory Context Header | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: NSH MD Type=0x1 Figure 4: NSH MD Type=0x1
This specification does not make any assumption about the content
placed in the mandatory context field of the NSH header, and does not
describe the structure or meaning of the included metadata.
An SFC-aware SF MUST receive the data semantics first in order to
process the data placed in the mandatory context field. The data
semantics include both the allocation schema and the meaning of the
included data. How an SFC-aware SF gets the data semantics is
outside the scope of this specification.
Upon receiving an NSH MD-type 1 packet, if the SFC-aware SF is
configured for mandatory use of metadata but does not yet receive the
data semantics for the mandatory context field, it MUST NOT process
the packet and MUST log at least once per the SPI for which a
mandatory metadata is missing.
[dcalloc] and [broadalloc] provide specific examples of how metadata [dcalloc] and [broadalloc] provide specific examples of how metadata
can be allocated. can be allocated.
3.5. NSH MD Type 2 3.5. NSH MD Type 2
When the base header specifies MD Type= 0x2, zero or more Variable When the base header specifies MD Type= 0x2, zero or more Variable
Length Context Headers MAY be added, immediately following the Length Context Headers MAY be added, immediately following the
Service Path Header. Therefore, Length = 0x2, indicates that only Service Path Header. Therefore, Length = 0x2, indicates that only
the Base Header followed by the Service Path Header are present. The the Base Header followed by the Service Path Header are present. The
optional Variable Length Context Headers MUST be of an integer number optional Variable Length Context Headers MUST be of an integer number
skipping to change at page 13, line 29 skipping to change at page 13, line 29
Length: Length of the variable metadata, in single byte words. In Length: Length of the variable metadata, in single byte words. In
case the metadata length is not an integer number of 4-byte words, case the metadata length is not an integer number of 4-byte words,
the sender MUST add pad bytes immediately following the last metadata the sender MUST add pad bytes immediately following the last metadata
byte to extend the metadata to an integer number of 4-byte words. byte to extend the metadata to an integer number of 4-byte words.
The receiver MUST round up the length field to the nearest 4-byte The receiver MUST round up the length field to the nearest 4-byte
word boundary, to locate and process the next field in the packet. word boundary, to locate and process the next field in the packet.
The receiver MUST access only those bytes in the metadata indicated The receiver MUST access only those bytes in the metadata indicated
by the length field (i.e. actual number of single byte words) and by the length field (i.e. actual number of single byte words) and
MUST ignore the remaining bytes up to the nearest 4-byte word MUST ignore the remaining bytes up to the nearest 4-byte word
boundary. A value of 0x0 or higher can be used. boundary. The Length may be 0 or greater.
A value of 0x0 denotes a TLV header without a Variable Metadata A value of 0x0 denotes a TLV header without a Variable Metadata
field. field.
4. NSH Actions 4. NSH Actions
NSH-aware nodes are the only nodes that MAY alter the content of the NSH-aware nodes are the only nodes that MAY alter the content of the
NSH headers. NSH-aware nodes include: service classifiers, SFF, SF NSH headers. NSH-aware nodes include: service classifiers, SFF, SF
and SFC proxies. These nodes have several possible header related and SFC proxies. These nodes have several possible header related
actions: actions:
skipping to change at page 17, line 9 skipping to change at page 17, line 9
The service header is independent of the encapsulation used and is The service header is independent of the encapsulation used and is
encapsulated in existing transports. The presence of NSH is encapsulated in existing transports. The presence of NSH is
indicated via protocol type or other indicator in the outer indicated via protocol type or other indicator in the outer
encapsulation. encapsulation.
6. Fragmentation Considerations 6. Fragmentation Considerations
NSH and the associated transport header are "added" to the NSH and the associated transport header are "added" to the
encapsulated packet/frame. This additional information increases the encapsulated packet/frame. This additional information increases the
size of the packet. In order to ensure proper forwarding of NSH size of the packet.
packets, several options for handling fragmentation and re-assembly
exist:
As discussed in [encap-considerations], within an administrative As discussed in [encap-considerations], within an administrative
domain, an operator can ensure that the underlay MTU is sufficient to domain, an operator can ensure that the underlay MTU is sufficient to
carry SFC traffic without requiring fragmentation. carry SFC traffic without requiring fragmentation.
However, there will be cases where the underlay MTU is not large However, there will be cases where the underlay MTU is not large
enough to carry the NSH traffic. Since NSH does not provide enough to carry the NSH traffic. Since NSH does not provide
fragmentation support at the service plane, the transport/overlay fragmentation support at the service plane, the transport/overlay
layer MUST provide the requisite fragmentation handling. Section 9 layer MUST provide the requisite fragmentation handling. Section 6
of [encap-considerations] provides guidance for those scenarios. of [encap-considerations] provides guidance for those scenarios.
7. Service Path Forwarding with NSH 7. Service Path Forwarding with NSH
7.1. SFFs and Overlay Selection 7.1. SFFs and Overlay Selection
As described above, NSH contains a Service Path Identifier (SPI) and As described above, NSH contains a Service Path Identifier (SPI) and
a Service Index (SI). The SPI is, as per its name, an identifier. a Service Index (SI). The SPI is, as per its name, an identifier.
The SPI alone cannot be used to forward packets along a service path. The SPI alone cannot be used to forward packets along a service path.
Rather the SPI provide a level of indirection between the service Rather the SPI provide a level of indirection between the service
skipping to change at page 18, line 25 skipping to change at page 18, line 25
or static network path. or static network path.
The Service Index provides an indication of location within a service The Service Index provides an indication of location within a service
path. The combination of SPI and SI provides the identification of a path. The combination of SPI and SI provides the identification of a
logical SF and its order within the service plane, and is used to logical SF and its order within the service plane, and is used to
select the appropriate network locator(s) for overlay forwarding. select the appropriate network locator(s) for overlay forwarding.
The logical SF may be a single SF, or a set of eligible SFs that are The logical SF may be a single SF, or a set of eligible SFs that are
equivalent. In the latter case, the SFF provides load distribution equivalent. In the latter case, the SFF provides load distribution
amongst the collection of SFs as needed. amongst the collection of SFs as needed.
SI can also serve as a mechanism for loop detection within a service SI serves as a mechanism for detecting invalid service function path.
path since each SF in the path decrements the index; an Service Index In particular, an SI value of zero indicates that forwarding is
of 0 indicates that a loop occurred and the packet must be discarded. incorrect and the packet must be discarded
This indirection -- path ID to overlay -- creates a true service This indirection -- path ID to overlay -- creates a true service
plane. That is the SFF/SF topology is constructed without impacting plane. That is the SFF/SF topology is constructed without impacting
the network topology but more importantly service plane only the network topology but more importantly service plane only
participants (i.e. most SFs) need not be part of the network overlay participants (i.e. most SFs) need not be part of the network overlay
topology and its associated infrastructure (e.g. control plane, topology and its associated infrastructure (e.g. control plane,
routing tables, etc.). As mentioned above, an existing overlay routing tables, etc.). As mentioned above, an existing overlay
topology may be used provided it offers the requisite connectivity. topology may be used provided it offers the requisite connectivity.
The mapping of SPI to transport occurs on an SFF (as discussed above, The mapping of SPI to transport occurs on an SFF (as discussed above,
skipping to change at page 21, line 41 skipping to change at page 21, line 41
packet is "on", and its location within that path simply by viewing packet is "on", and its location within that path simply by viewing
the NSH information (packet capture, IPFIX, etc.). The information the NSH information (packet capture, IPFIX, etc.). The information
can be used for service scheduling and placement decisions, can be used for service scheduling and placement decisions,
troubleshooting and compliance verification. troubleshooting and compliance verification.
7.4. Service Graphs 7.4. Service Graphs
While a given realized service function path is a specific sequence While a given realized service function path is a specific sequence
of service functions, the service as seen by a user can actually be a of service functions, the service as seen by a user can actually be a
collection of service function paths, with the interconnection collection of service function paths, with the interconnection
provided by classifiers (in-service path, non-initial re- provided by classifiers (in-service path, non-initial
classification). These internal re-classifiers examine the packet at reclassification). These internal reclassifiers examine the packet
relevant points in the network, and, if needed, SPI and SI are at relevant points in the network, and, if needed, SPI and SI are
updated (whether this update is a re-write, or the imposition of a updated (whether this update is a re-write, or the imposition of a
new NSH with new values is implementation specific) to reflect the new NSH with new values is implementation specific) to reflect the
"result" of the classification. These classifiers may also of course "result" of the classification. These classifiers may also of course
modify the metadata associated with the packet. modify the metadata associated with the packet.
RFC7665, section 2.1 describes Service Graphs in detail. RFC7665, section 2.1 describes Service Graphs in detail.
8. Policy Enforcement with NSH 8. Policy Enforcement with NSH
8.1. NSH Metadata and Policy Enforcement 8.1. NSH Metadata and Policy Enforcement
skipping to change at page 24, line 6 skipping to change at page 24, line 6
did not need to perform re-classification, rather they rely on a did not need to perform re-classification, rather they rely on a
antecedent classification for local policy enforcement. antecedent classification for local policy enforcement.
Depending on the information carried in the metadata, data privacy Depending on the information carried in the metadata, data privacy
considerations may need to be considered. For example, if the considerations may need to be considered. For example, if the
metadata conveys tenant information, that information may need to be metadata conveys tenant information, that information may need to be
authenticated and/or encrypted between the originator and the authenticated and/or encrypted between the originator and the
intended recipients (which may include intended SFs only) . NSH intended recipients (which may include intended SFs only) . NSH
itself does not provide privacy functions, rather it relies on the itself does not provide privacy functions, rather it relies on the
transport/overlay layer. An operator can select the appropriate transport/overlay layer. An operator can select the appropriate
transport to ensure the confidentiality (and other security) transport to ensure the confidentially (and other security)
considerations are met. considerations are met.
8.2. Updating/Augmenting Metadata 8.2. Updating/Augmenting Metadata
Post-initial metadata imposition (typically performed during initial Post-initial metadata imposition (typically performed during initial
service path determination), metadata may be augmented or updated: service path determination), metadata may be augmented or updated:
1. Metadata Augmentation: Information may be added to NSH's existing 1. Metadata Augmentation: Information may be added to NSH's existing
metadata, as depicted in Figure 15. For example, if the initial metadata, as depicted in Figure 15. For example, if the initial
classification returns the tenant information, a secondary classification returns the tenant information, a secondary
skipping to change at page 25, line 23 skipping to change at page 25, line 23
`---' `---' `---' `---' `---' `---'
5-tuple: Inspect Deny 5-tuple: Inspect Deny
Tenant A Tenant A attack Tenant A Tenant A attack
--> attack --> attack
Figure 16: Metadata Update Figure 16: Metadata Update
8.3. Service Path Identifier and Metadata 8.3. Service Path Identifier and Metadata
Metadata information may influence the service path selection since Metadata information may influence the service path selection since
the Service Path Identifier and Service Index values can represent the Service Path Identifier values can represent the result of
the result of classification. A given SPI and SI can be defined classification. A given SPI can be defined based on classification
based on classification results (including metadata classification). results (including metadata classification). The imposition of the
The imposition of the SPI/SI (new or an change of existing) reflect, SPI and SI results in the packet being placed on the newly specified
as previously described, the new SFP. SFP at the position indicated by the imposed SPI and SI.
This relationship provides the ability to create a dynamic service This relationship provides the ability to create a dynamic service
plane based on complex classification without requiring each node to plane based on complex classification without requiring each node to
be capable of such classification, or requiring a coupling to the be capable of such classification, or requiring a coupling to the
network topology. This yields service graph functionality as network topology. This yields service graph functionality as
described in Section 7.4. Figure 17 illustrates an example of this described in Section 7.4. Figure 17 illustrates an example of this
behavior. behavior.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| SFF |---------> | SFF |------+---> | SFF | | SFF |---------> | SFF |------+---> | SFF |
skipping to change at page 27, line 8 skipping to change at page 27, line 8
"Scrubber" "Scrubber"
Figure 17: Path ID and Metadata Figure 17: Path ID and Metadata
Specific algorithms for mapping metadata to an SPI are outside the Specific algorithms for mapping metadata to an SPI are outside the
scope of this document. scope of this document.
9. Security Considerations 9. Security Considerations
As with many other protocols, NSH data can be spoofed or otherwise As with many other protocols, NSH data can be spoofed or otherwise
modified. As noted in the descriptive text in [sfc-security- modified. In many deployments, NSH will be used in a controlled
requirements], in many deployments, NSH will be used in a controlled
environment, with trusted devices (e.g. a data center) thus environment, with trusted devices (e.g. a data center) thus
mitigating the risk of unauthorized header manipulation. As noted mitigating the risk of unauthorized header manipulation.
there, far fewer protection mechanisms are needed in these
environments, which are the primary design target of NSH.
NSH is always encapsulated in a transport protocol and therefore, NSH is always encapsulated in a transport protocol and therefore,
when required, existing security protocols that provide authenticity when required, existing security protocols that provide authenticity
(e.g. [ [RFC6071]) can be used between SFF or even to SF. Similarly (e.g. [RFC6071]) can be used. Similarly, if confidentiality is
if confidentiality is required, existing encryption protocols can be required, existing encryption protocols can be used in conjunction
used in conjunction with encapsulated NSH. with encapsulated NSH.
Further, existing best practices, such as [RFC2827] should be Further, existing best practices, such as [BCP38] should be deployed
deployed at the network layer to ensure that traffic entering the at the network layer to ensure that traffic entering the service path
service path is indeed "valid". [encap-considerations] provides is indeed "valid". [encap-considerations] provides additional
additional transport encapsulation considerations. transport encapsulation considerations.
NSH metadata authenticity and confidentiality must be considered as NSH metadata authenticity and confidentially must be considered as
well. In order to protect the metadata, an operator can leverage the well. In order to protect the metadata, an operator can leverage the
aforementioned mechanisms provided the transport layer, authenticity aforementioned mechanisms provided the transport layer, authenticity
and/or confidentiality. An operator MUST carefully select the and/or confidentiality. An operator MUST carefully select the
transport/underlay services to ensure end to end security services, transport/underlay services to ensure end to end security services,
when those are sought after. For example, if RFC6071 is used, the when those are sought after. For example, if [RFC6071] is used, the
operator MUST ensure it can be supported by the transport/underlay of operator MUST ensure it can be supported by the transport/underlay of
all relevant network segments as well as SFF and SFs. Further, as all relevant network segments as well as SFF and SFs. Further, as
described in [section 8.1], operators can and should use indirect described in [section 8.1], operators can and should use indirect
identification for personally identifying information, thus identification for personally identifying information, thus
significantly mitigating the risk of privacy violation. significantly mitigating the risk of privacy violation.
Further, the extensibility of MD Type 2 to add information to
packets, and where needed to mark that data as critical, allows for
attaching signatures or even encryption keying information to the NSH
header in the future. Based on the learnings from the work on [nsh-
sec], it appears likely that this can provide any needed NSH-specific
security mechanisms in the future.
Lastly, SF security, although out of scope of this document, should Lastly, SF security, although out of scope of this document, should
be considered, particularly if an SF needs to access, authenticate or be considered, particularly if an SF needs to access, authenticate or
update NSH metadata. update NSH metadata.
Further security considerations are discussed in [nsh-sec].
10. Contributors 10. Contributors
This WG document originated as draft-quinn-sfc-nsh and had the This WG document originated as draft-quinn-sfc-nsh and had the
following co-authors and contributors. The editors of this document following co-authors and contributors. The editors of this document
would like to thank and recognize them and their contributions. would like to thank and recognize them and their contributions.
These co-authors and contributors provided invaluable concepts and These co-authors and contributors provided invaluable concepts and
content for this document's creation. content for this document's creation.
Surendra Kumar Surendra Kumar
Cisco Systems Cisco Systems
skipping to change at page 31, line 22 skipping to change at page 31, line 22
A special thank you goes to David Ward and Tom Edsall for their A special thank you goes to David Ward and Tom Edsall for their
guidance and feedback. guidance and feedback.
Additionally the authors would like to thank Carlos Pignataro and Additionally the authors would like to thank Carlos Pignataro and
Larry Kreeger for their invaluable ideas and contributions which are Larry Kreeger for their invaluable ideas and contributions which are
reflected throughout this document. reflected throughout this document.
Loa Andersson provided a thorough review and valuable comments, we Loa Andersson provided a thorough review and valuable comments, we
thank him for that. thank him for that.
Lastly, Reinaldo Penno deserves a particular thank you for his Reinaldo Penno deserves a particular thank you for his architecture
architecture and implementation work that helped guide the protocol and implementation work that helped guide the protocol concepts and
concepts and design. design.
Lastly, David Dolson has provides significant review, feedback and
suggestions throughout the evolution of this document. His
contributions are very much appreciated.
12. IANA Considerations 12. IANA Considerations
12.1. NSH EtherType 12.1. NSH EtherType
An IEEE EtherType, 0x894F, has been allocated for NSH. An IEEE EtherType, 0x894F, has been allocated for NSH.
12.2. Network Service Header (NSH) Parameters 12.2. Network Service Header (NSH) Parameters
IANA is requested to create a new "Network Service Header (NSH) IANA is requested to create a new "Network Service Header (NSH)
skipping to change at page 33, line 38 skipping to change at page 33, line 38
0x0000 to 0x01ff: IETF Review 0x0000 to 0x01ff: IETF Review
0x0200 to 0xfff5: Expert Review 0x0200 to 0xfff5: Expert Review
0xfff6 to 0xfffe: Experimental 0xfff6 to 0xfffe: Experimental
0xffff: Reserved 0xffff: Reserved
12.2.5. NSH Base Header Next Protocol 12.2.5. NSH Base Header Next Protocol
IANA is requested to set up a registry of "Next Protocol". These are IANA is requested to set up a registry of "Next Protocol". These are
8-bit values. Next Protocol values 0, 1, 2, 3, 4 and 5 are defined 8-bit values. Next Protocol values 0, 1, 2, 3, 4 and 5 are defined
in this draft. New values are assigned via Standards Action in this draft. New values are assigned via "Expert Reviews" as per
[RFC5226]. [RFC5226].
+---------------+--------------+---------------+ +---------------+--------------+---------------+
| Next Protocol | Description | Reference | | Next Protocol | Description | Reference |
+---------------+--------------+---------------+ +---------------+--------------+---------------+
| 0 | Reserved | This document | | 0 | Reserved | This document |
| | | | | | | |
| 1 | IPv4 | This document | | 1 | IPv4 | This document |
| | | | | | | |
| 2 | IPv6 | This document | | 2 | IPv6 | This document |
skipping to change at page 35, line 19 skipping to change at page 35, line 19
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/
RFC7665, October 2015,
<http://www.rfc-editor.org/info/rfc7665>.
13.2. Informative References 13.2. Informative References
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000, DOI 10.17487/RFC2784, March 2000,
<http://www.rfc-editor.org/info/rfc2784>. <http://www.rfc-editor.org/info/rfc2784>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
skipping to change at page 35, line 46 skipping to change at page 35, line 51
[RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A.,
and C. Pignataro, "MPLS Forwarding Compliance and and C. Pignataro, "MPLS Forwarding Compliance and
Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, Performance Requirements", RFC 7325, DOI 10.17487/RFC7325,
August 2014, <http://www.rfc-editor.org/info/rfc7325>. August 2014, <http://www.rfc-editor.org/info/rfc7325>.
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
Service Function Chaining", RFC 7498, DOI 10.17487/ Service Function Chaining", RFC 7498, DOI 10.17487/
RFC7498, April 2015, RFC7498, April 2015,
<http://www.rfc-editor.org/info/rfc7498>. <http://www.rfc-editor.org/info/rfc7498>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/
RFC7665, October 2015,
<http://www.rfc-editor.org/info/rfc7665>.
[SFC-CP] Boucadair, M., "Service Function Chaining (SFC) Control [SFC-CP] Boucadair, M., "Service Function Chaining (SFC) Control
Plane Components & Requirements", 2016, <https:// Plane Components & Requirements", 2016, <https://
datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/>. datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/>.
[VXLAN-gpe] [VXLAN-gpe]
Quinn, P., Manur, R., Agarwal, P., Kreeger, L., Lewis, D., Quinn, P., Manur, R., Agarwal, P., Kreeger, L., Lewis, D.,
Maino, F., Smith, M., Yong, L., Xu, X., Elzur, U., Garg, Maino, F., Smith, M., Yong, L., Xu, X., Elzur, U., Garg,
P., and D. Melman, "Generic Protocol Extension for VXLAN", P., and D. Melman, "Generic Protocol Extension for VXLAN",
<https://datatracker.ietf.org/doc/ <https://datatracker.ietf.org/doc/
draft-ietf-nvo3-vxlan-gpe/>. draft-ietf-nvo3-vxlan-gpe/>.
[bcp38] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", 2000,
<https://tools.ietf.org/html/bcp38>.
[broadalloc] [broadalloc]
Napper, J., Kumar, S., Muley, P., and W. Hendericks, "NSH Napper, J., Kumar, S., Muley, P., and W. Hendericks, "NSH
Context Header Allocation -- Mobility", 2016, <https:// Context Header Allocation -- Mobility", 2016, <https://
datatracker.ietf.org/doc/ datatracker.ietf.org/doc/
draft-napper-sfc-nsh-broadband-allocation/>. draft-napper-sfc-nsh-broadband-allocation/>.
[dcalloc] Guichard, J., Smith, M., and et al., "Network Service [dcalloc] Guichard, J., Smith, M., and et al., "Network Service
Header (NSH) Context Header Allocation (Data Center)", Header (NSH) Context Header Allocation (Data Center)",
2016, <https://datatracker.ietf.org/doc/ 2016, <https://datatracker.ietf.org/doc/
draft-guichard-sfc-nsh-dc-allocation/>. draft-guichard-sfc-nsh-dc-allocation/>.
[encap-considerations] [encap-considerations]
Nordmark, E., Tian, A., Gross, J., Hudson, J., Kreeger, Nordmark, E., Tian, A., Gross, J., Hudson, J., Kreeger,
L., Garg, P., Thaler, P., and T. Herbert, "Encapsulation L., Garg, P., Thaler, P., and T. Herbert, "Encapsulation
Considerations", <https://datatracker.ietf.org/doc/ Considerations", <https://datatracker.ietf.org/doc/
draft-ietf-rtgwg-dt-encap/>. draft-ietf-rtgwg-dt-encap/>.
[nsh-sec] Reddy, T., Migault, D., Pignataro, C., Quinn, P., and C. [nsh-env-req]
Inacio, "NSH Security and Privacy requirements", 2016, <ht Migault, D., Pignataro, C., Reddy, T., and C. Inacio, "SFC
tps://datatracker.ietf.org/doc/ environment Security requirements", 2016, <https://
draft-reddy-sfc-nsh-security-req/>. www.ietf.org/id/
draft-mglt-sfc-security-environment-req-02.txt>.
Authors' Addresses Authors' Addresses
Paul Quinn (editor) Paul Quinn (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Email: paulq@cisco.com Email: paulq@cisco.com
Uri Elzur (editor) Uri Elzur (editor)
Intel Intel
 End of changes. 30 change blocks. 
79 lines changed or deleted 83 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/