draft-ietf-sfc-nsh-09.txt   draft-ietf-sfc-nsh-10.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 19, 2017 Intel Expires: March 24, 2017 Intel
September 15, 2016 September 20, 2016
Network Service Header Network Service Header
draft-ietf-sfc-nsh-09.txt draft-ietf-sfc-nsh-10.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 19, 2017. This Internet-Draft will expire on March 24, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 16, line 23 skipping to change at page 17, line 5
underlying network topology underlying network topology
2. Transit network nodes simply forward the encapsulated packets as 2. Transit network nodes simply forward the encapsulated packets as
is. is.
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.
See Section 9 for NSH encapsulation examples.
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. In order to ensure proper forwarding of NSH
packets, several options for handling fragmentation and re-assembly packets, several options for handling fragmentation and re-assembly
exist: 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
skipping to change at page 24, line 15 skipping to change at page 24, line 15
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 confidentiality (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 17. 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
classification (perhaps co-resident with DPI or SLB) may augment classification (perhaps co-resident with DPI or SLB) may augment
the tenant classification with application information, and the tenant classification with application information, and
impose that new information in the NSH metadata. The tenant impose that new information in the NSH metadata. The tenant
classification is still valid and present, but additional classification is still valid and present, but additional
information has been added to it. information has been added to it.
2. Metadata Update: Subsequent classifiers may update the initial 2. Metadata Update: Subsequent classifiers may update the initial
classification if it is determined to be incorrect or not classification if it is determined to be incorrect or not
descriptive enough. For example, the initial classifier adds descriptive enough. For example, the initial classifier adds
skipping to change at page 26, line 10 skipping to change at page 26, line 10
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 |
+--+--+ +--+--+ | +--+--+ +--+--+ +--+--+ | +--+--+
| | | | | | | |
,---. ,---. | ,---. ,---. ,---. | ,---.
/ \ / \ | / \ / \ / SF1 \ | / \
( SCL ) ( SF1 ) | ( SF2 ) ( SCL ) ( + ) | ( SF2 )
\ / \ / | \ / \ / \SCL2 / | \ /
`---' `---' +-----+ `---' `---' `---' +-----+ `---'
5-tuple: Inspect | SFF | Original 5-tuple: Inspect | SFF | Original
Tenant A Tenant A +--+--+ next SF Tenant A Tenant A +--+--+ next SF
--> DoS | --> DoS |
V V
,-+-. ,-+-.
/ \ / \
( SF10 ) ( SF10 )
\ / \ /
`---' `---'
skipping to change at page 27, line 21 skipping to change at page 27, line 21
mitigating the risk of unauthorized header manipulation. As noted mitigating the risk of unauthorized header manipulation. As noted
there, far fewer protection mechanisms are needed in these there, far fewer protection mechanisms are needed in these
environments, which are the primary design target of NSH. 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 between SFF or even to SF. Similarly
if confidentiality is required, existing encryption protocols can be if confidentiality is required, existing encryption protocols can be
used in conjunction with encapsulated NSH. used in conjunction with encapsulated NSH.
Further, existing best practices, such as [BCP38] should be deployed Further, existing best practices, such as [RFC2827] should be
at the network layer to ensure that traffic entering the service path deployed at the network layer to ensure that traffic entering the
is indeed "valid". [encap-considerations] provides additional service path is indeed "valid". [encap-considerations] provides
transport encapsulation considerations. additional transport encapsulation considerations.
NSH metadata authenticity and confidentiality must be considered as NSH metadata authenticity and confidentiality 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
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>.
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
Service Function Chaining", RFC 7498, DOI 10.17487/
RFC7498, April 2015,
<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>.
13.2. Informative References 13.2. Informative References
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990,
<http://www.rfc-editor.org/info/rfc1191>.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, DOI 10.17487/RFC1981,
August 1996, <http://www.rfc-editor.org/info/rfc1981>.
[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:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[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,
<http://www.rfc-editor.org/info/rfc6071>. <http://www.rfc-editor.org/info/rfc6071>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013,
<http://www.rfc-editor.org/info/rfc6830>.
[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
Service Function Chaining", RFC 7498, DOI 10.17487/
RFC7498, April 2015,
<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/>.
 End of changes. 12 change blocks. 
37 lines changed or deleted 27 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/