draft-ietf-sfc-nsh-25.txt   draft-ietf-sfc-nsh-26.txt 
Service Function Chaining P. Quinn, Ed. Service Function Chaining P. Quinn, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track U. Elzur, Ed. Intended status: Standards Track U. Elzur, Ed.
Expires: April 1, 2018 Intel Expires: April 8, 2018 Intel
C. Pignataro, Ed. C. Pignataro, Ed.
Cisco Cisco
September 28, 2017 October 5, 2017
Network Service Header (NSH) Network Service Header (NSH)
draft-ietf-sfc-nsh-25 draft-ietf-sfc-nsh-26
Abstract Abstract
This document describes a Network Service Header (NSH) imposed on This document describes a Network Service Header (NSH) imposed on
packets or frames to realize service function paths. The NSH also packets or frames to realize service function paths. The NSH also
provides a mechanism for metadata exchange along the instantiated provides a mechanism for metadata exchange along the instantiated
service paths. The NSH is the SFC encapsulation required to support service paths. The NSH is the SFC encapsulation required to support
the Service Function Chaining (SFC) architecture (defined in the Service Function Chaining (SFC) architecture (defined in
RFC7665). RFC7665).
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 April 1, 2018. This Internet-Draft will expire on April 8, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 8, line 33 skipping to change at page 8, line 33
does not understnad the version of the protocol as indicated in the does not understnad the version of the protocol as indicated in the
base header, the packet MUST be discarded, and the event SHOULD be base header, the packet MUST be discarded, and the event SHOULD be
logged. Given the widespread implementation of existing hardware logged. Given the widespread implementation of existing hardware
that uses the first nibble after an MPLS label stack for equal-cost that uses the first nibble after an MPLS label stack for equal-cost
multipath (ECMP) decision processing, this document reserves version multipath (ECMP) decision processing, this document reserves version
01b. This value MUST NOT be used in future versions of the protocol. 01b. This value MUST NOT be used in future versions of the protocol.
Please see [RFC7325] for further discussion of MPLS-related Please see [RFC7325] for further discussion of MPLS-related
forwarding requirements. forwarding requirements.
O bit: Setting this bit indicates an Operations, Administration, and O bit: Setting this bit indicates an Operations, Administration, and
Maintenance (OAM) packet. The actual format and processing of SFC Maintenance (OAM, see [RFC6291]) packet. The actual format and
OAM packets is outside the scope of this specification (see for processing of SFC OAM packets is outside the scope of this
example [I-D.ietf-sfc-oam-framework] for one approach). specification (see for example [I-D.ietf-sfc-oam-framework] for one
approach).
The O bit MUST be set for OAM packets and MUST NOT be set for non-OAM The O bit MUST be set for OAM packets and MUST NOT be set for non-OAM
packets. The O bit MUST NOT be modified along the SFP. packets. The O bit MUST NOT be modified along the SFP.
SF/SFF/SFC Proxy/Classifier implementations that do not support SFC SF/SFF/SFC Proxy/Classifier implementations that do not support SFC
OAM procedures SHOULD discard packets with O bit set, but MAY support OAM procedures SHOULD discard packets with O bit set, but MAY support
a configurable parameter to enable forwarding received SFC OAM a configurable parameter to enable forwarding received SFC OAM
packets unmodified to the next element in the chain. Forwarding OAM packets unmodified to the next element in the chain. Forwarding OAM
packets unmodified by SFC elements that do not support SFC OAM packets unmodified by SFC elements that do not support SFC OAM
procedures may be acceptable for a subset of OAM functions, but can procedures may be acceptable for a subset of OAM functions, but can
skipping to change at page 9, line 15 skipping to change at page 9, line 15
TTL: Indicates the maximum SFF hops for an SFP. This field is used TTL: Indicates the maximum SFF hops for an SFP. This field is used
for service plane loop detection. The initial TTL value SHOULD be for service plane loop detection. The initial TTL value SHOULD be
configurable via the control plane; the configured initial value can configurable via the control plane; the configured initial value can
be specific to one or more SFPs. If no initial value is explicitly be specific to one or more SFPs. If no initial value is explicitly
provided, the default initial TTL value of 63 MUST be used. Each SFF provided, the default initial TTL value of 63 MUST be used. Each SFF
involved in forwarding an NSH packet MUST decrement the TTL value by involved in forwarding an NSH packet MUST decrement the TTL value by
1 prior to NSH forwarding lookup. Decrementing by 1 from an incoming 1 prior to NSH forwarding lookup. Decrementing by 1 from an incoming
value of 0 shall result in a TTL value of 63. The packet MUST NOT be value of 0 shall result in a TTL value of 63. The packet MUST NOT be
forwarded if TTL is, after decrement, 0. forwarded if TTL is, after decrement, 0.
This TTL field is the primary loop prevention This TTL mechanism This TTL field is the primary loop prevention mechanism. This TTL
represents a robust complement to the Service Index (see mechanism represents a robust complement to the Service Index (see
Section 2.3), as the TTL is decrement by each SFF. The handling of Section 2.3), as the TTL is decrement by each SFF. The handling of
incoming 0 TTL allows for better, although not perfect, incoming 0 TTL allows for better, although not perfect,
interoperation with pre-standard implementations that do not support interoperation with pre-standard implementations that do not support
this TTL field. this TTL field.
Unassigned bits: All other flag fields, marked U, are unassigned and
available for future use, see Section 11.1.1. Unassigned bits MUST
be set to zero upon origination, and MUST be ignored and preserved
unmodified by other NSH supporting elements. At reception, all
elements MUST NOT modify their actions based on these unknown bits.
Length: The total length, in 4-byte words, of the NSH including the Length: The total length, in 4-byte words, of the NSH including the
Base Header, the Service Path Header, the Fixed Length Context Header Base Header, the Service Path Header, the Fixed Length Context Header
or Variable Length Context Header(s). The length MUST be 0x6 for MD or Variable Length Context Header(s). The length MUST be 0x6 for MD
Type equal to 0x1, and MUST be 0x2 or greater for MD Type equal to Type equal to 0x1, and MUST be 0x2 or greater for MD Type equal to
0x2. The length of the NSH header MUST be an integer multiple of 4 0x2. The length of the NSH header MUST be an integer multiple of 4
bytes, thus variable length metadata is always padded out to a bytes, thus variable length metadata is always padded out to a
multiple of 4 bytes. multiple of 4 bytes.
Unassigned bits: All other flag fields, marked U, are unassigned and
available for future use, see Section 11.1.1. Unassigned bits MUST
be set to zero upon origination, and MUST be ignored and preserved
unmodified by other NSH supporting elements. At reception, all
elements MUST NOT modify their actions based on these unknown bits.
Metadata (MD) Type: Indicates the format of the NSH beyond the Metadata (MD) Type: Indicates the format of the NSH beyond the
mandatory Base Header and the Service Path Header. MD Type defines mandatory Base Header and the Service Path Header. MD Type defines
the format of the metadata being carried. Please see the IANA the format of the metadata being carried. Please see the IANA
Considerations Section 11.1.3. Considerations Section 11.1.3.
This document specifies the following four MD Type values: This document specifies the following four MD Type values:
0x0 - This is a reserved value. Implementations SHOULD silently 0x0 - This is a reserved value. Implementations SHOULD silently
discard packets with MD Type 0x0. discard packets with MD Type 0x0.
skipping to change at page 12, line 31 skipping to change at page 12, line 31
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: NSH MD Type=0x1 Figure 5: NSH MD Type=0x1
This specification does not make any assumptions about the content of This specification does not make any assumptions about the content of
the 16 byte Context Header that must be present when the MD Type the 16 byte Context Header that must be present when the MD Type
field is set to 1, and does not describe the structure or meaning of field is set to 1, and does not describe the structure or meaning of
the included metadata. the included metadata.
An SFC-aware SF or SFC Proxy MUST receive the data semantics first in An SFC-aware SF or SFC Proxy needs to receive the data semantics
order to process the data placed in the mandatory context field. The first in order to process the data placed in the mandatory context
data semantics include both the allocation schema and the meaning of field. The data semantics include both the allocation schema and the
the included data. How an SFC-aware SF or SFC Proxy gets the data meaning of the included data. How an SFC-aware SF or SFC Proxy gets
semantics is outside the scope of this specification. the data semantics is outside the scope of this specification.
An SF or SFC Proxy that does not know the format or semantics of the An SF or SFC Proxy that does not know the format or semantics of the
Context Header for an NSH with MD Type 1 MUST discard any packet with Context Header for an NSH with MD Type 1 MUST discard any packet with
such an NSH (i.e., MUST NOT ignore the metadata that it cannot such an NSH (i.e., MUST NOT ignore the metadata that it cannot
process), and MUST log the event at least once per the SPI for which process), and MUST log the event at least once per the SPI for which
the event occurs (subject to thresholding). the event occurs (subject to thresholding).
[I-D.guichard-sfc-nsh-dc-allocation] and [I-D.guichard-sfc-nsh-dc-allocation] and
[I-D.napper-sfc-nsh-broadband-allocation] provide specific examples [I-D.napper-sfc-nsh-broadband-allocation] provide specific examples
of how metadata can be allocated. of how metadata can be allocated.
skipping to change at page 23, line 51 skipping to change at page 23, line 51
AppZ AppZ
Figure 10: External Metadata and Policy Figure 10: External Metadata and Policy
In both of the examples above, the service functions perform policy In both of the examples above, the service functions perform policy
decisions based on the result of the initial classification: the SFs decisions based on the result of the initial classification: the SFs
did not need to perform re-classification; instead, they rely on a did not need to perform re-classification; instead, 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 impact needs to be considered. For example, if the metadata conveys
metadata conveys tenant information, that information may need to be tenant information, that information may need to be authenticated
authenticated and/or encrypted between the originator and the and/or encrypted between the originator and the intended recipients
intended recipients (which may include intended SFs only); one (which may include intended SFs only); one approach to an optional
approach to an optional capability to do this is explored in capability to do this is explored in [I-D.reddy-sfc-nsh-encrypt].
[I-D.reddy-sfc-nsh-encrypt]. The NSH itself does not provide privacy The NSH itself does not provide privacy functions, rather it relies
functions, rather it relies on the transport encapsulation/overlay. on the transport encapsulation/overlay. An operator can select the
An operator can select the appropriate set of transport encapsulation appropriate set of transport encapsulation protocols to ensure
protocols to ensure confidentiality (and other security) confidentiality (and other security) considerations are met.
considerations are met. Metadata privacy and security considerations Metadata privacy and security considerations are a matter for the
are a matter for the documents that define metadata format. documents that define metadata format.
7.2. Updating/Augmenting Metadata 7.2. Updating/Augmenting Metadata
Post-initial metadata imposition (typically performed during initial Post-initial metadata imposition (typically performed during initial
service path determination), the metadata may be augmented or service path determination), the metadata may be augmented or
updated: updated:
1. Metadata Augmentation: Information may be added to the NSH's 1. Metadata Augmentation: Information may be added to the NSH's
existing metadata, as depicted in Figure 11. For example, if the existing metadata, as depicted in Figure 11. For example, if the
initial classification returns the tenant information, a initial classification returns the tenant information, a
skipping to change at page 36, line 31 skipping to change at page 36, line 31
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, Considered Useful", BCP 82, RFC 3692,
DOI 10.17487/RFC3692, January 2004, DOI 10.17487/RFC3692, January 2004,
<https://www.rfc-editor.org/info/rfc3692>. <https://www.rfc-editor.org/info/rfc3692>.
[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and
Internet Key Exchange (IKE) Document Roadmap", RFC 6071, Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
DOI 10.17487/RFC6071, February 2011, DOI 10.17487/RFC6071, February 2011,
<https://www.rfc-editor.org/info/rfc6071>. <https://www.rfc-editor.org/info/rfc6071>.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291,
DOI 10.17487/RFC6291, June 2011,
<https://www.rfc-editor.org/info/rfc6291>.
[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, <https://www.rfc-editor.org/info/rfc7325>. August 2014, <https://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, Service Function Chaining", RFC 7498,
DOI 10.17487/RFC7498, April 2015, DOI 10.17487/RFC7498, April 2015,
<https://www.rfc-editor.org/info/rfc7498>. <https://www.rfc-editor.org/info/rfc7498>.
 End of changes. 11 change blocks. 
31 lines changed or deleted 38 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/