< draft-malis-mpls-sfc-encapsulation-02.txt		draft-malis-mpls-sfc-encapsulation-03.txt >
	MPLS Working Group A. Malis		MPLS Working Group A. Malis
	Internet-Draft S. Bryant		Internet-Draft S. Bryant
	Intended status: Informational Huawei Technologies		Intended status: Informational Huawei Technologies
	Expires: March 15, 2019 J. Halpern		Expires: April 14, 2019 J. Halpern
	Ericsson		Ericsson
	W. Henderickx		W. Henderickx
	Nokia		Nokia
	September 11, 2018		October 11, 2018
	MPLS Encapsulation for SFC NSH		MPLS Encapsulation for SFC NSH
	draft-malis-mpls-sfc-encapsulation-02		draft-malis-mpls-sfc-encapsulation-03
	Abstract		Abstract
	This document describes how to use a Service Function Forwarder (SFF)		This document describes how to use a Service Function Forwarder (SFF)
	Label (similar to a pseudowire label or VPN label) to indicate the		Label (similar to a pseudowire label or VPN label) to indicate the
	presence of a Service Function Chaining (SFC) Network Service Header		presence of a Service Function Chaining (SFC) Network Service Header
	(NSH) between an MPLS label stack and the packet payload. This		(NSH) between an MPLS label stack and the packet payload. This
	allows SFC packets using the NSH to be forwarded between SFFs over an		allows SFC packets using the NSH to be forwarded between SFFs over an
	MPLS network, and the selection between multiple SFFs in the		MPLS network, and the selection between multiple SFFs in the
	destination MPLS node.		destination MPLS node.
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 March 15, 2019.		This Internet-Draft will expire on April 14, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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 3, line 20 ¶		skipping to change at page 3, line 20 ¶
	The encapsulation is a standard MPLS label stack [RFC3032] with an		The encapsulation is a standard MPLS label stack [RFC3032] with an
	SFF Label at the bottom of the stack, followed by a NSH as defined by		SFF Label at the bottom of the stack, followed by a NSH as defined by
	[RFC8300] and the NSH payload.		[RFC8300] and the NSH payload.
	Much like a pseudowire label, an SFF Label is allocated by the		Much like a pseudowire label, an SFF Label is allocated by the
	downstream receiver of the NSH from its per-platform label space.		downstream receiver of the NSH from its per-platform label space.
	If a receiving node supports more than one SFF (i.e, more than one		If a receiving node supports more than one SFF (i.e, more than one
	SFC forwarding instance), then the SFF Label can be used to select		SFC forwarding instance), then the SFF Label can be used to select
	the proper SFF, by having the receiving advertise more than one SFF		the proper SFF, by having the receiving node advertise more than one
	Label to its upstream sending nodes as appropriate.		SFF Label to its upstream sending nodes as appropriate.
	The method used by the downstream receiving node to advertise SFF		The method used by the downstream receiving node to advertise SFF
	Labels to the upstream sending node is out of scope of this document.		Labels to the upstream sending node is out of scope of this document.
	That said, a number of methods are possible, such as via a protocol		That said, a number of methods are possible, such as via a protocol
	exchange, or via a controller that manages both the sender and the		exchange, or via a controller that manages both the sender and the
	receiver using NETCONF/YANG, BGP, PCEP, etc. These are meant as		receiver using NETCONF/YANG, BGP, PCEP, etc. These are meant as
	possible examples and not to constrain the future definition of such		possible examples and not to constrain the future definition of such
	advertisement methods.		advertisement methods.
	While the SFF label will usually be at the bottom of the label stack,		While the SFF label will usually be at the bottom of the label stack,
	there may be cases where additional label stack entries beneath it.		there may be cases where there are additional label stack entries
	For example, when ACH is carried that applies to the SFF, a GAL		beneath it. For example, when an ACH is carried that applies to the
	[RFC5586] will be in the label stack below the SFF. Similarly, an		SFF, a GAL [RFC5586] will be in the label stack below the SFF.
	ELI/EL [RFC6790] may be carried below the SFF in the label stack.		Similarly, an ELI/EL [RFC6790] may be carried below the SFF in the
	This is identical to the situation with VPN labels.		label stack. This is identical to the situation with VPN labels.
	2.1. MPLS Label Stack Construction at the Sending Node		2.1. MPLS Label Stack Construction at the Sending Node
	When one SFF wishes to send an SFC packet with the NSF to another SFF		When one SFF wishes to send an SFC packet with the NSH to another SFF
	over an MPLS transport network, a label stack needs to be constructed		over an MPLS transport network, a label stack needs to be constructed
	by the MPLS node that contains the sending SFF in order to transport		by the MPLS node that contains the sending SFF in order to transport
	the packet to the destination MPLS node that contains the receiving		the packet to the destination MPLS node that contains the receiving
	SFF. The label can be constructed as follows:		SFF. The label can be constructed as follows:
	1. Push on zero or more labels that are interpreted by the		1. Push on zero or more labels that are interpreted by the
	destination MPLS node, such as the Generic Associated Channel		destination MPLS node, such as the Generic Associated Channel
	[RFC5586] label (see OAM Considerations below).		[RFC5586] label (see OAM Considerations below).
	2. Push on the SFF Label to identify the desired SFF in the		2. Push on the SFF Label to identify the desired SFF in the
End of changes. 7 change blocks.
	12 lines changed or deleted		12 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/