charter-ietf-spring-02.txt		charter-ietf-spring-02-01.txt
	The Source Packet Routing in NetworkinG (SPRING) Working Group is the		The Source Packet Routing in NetworkinG (SPRING) Working Group is the
	home of Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6).		home of Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6).
	SPRING WG serves as a forum to discuss SPRING networks operations,		The SPRING WG is responsible for defining new applications and
	define new applications of, and specify extensions of Segment Routing		specifying extensions of Segment Routing technologies. It also serves
	technologies.		as a forum to discuss SR-MPLS network operations.
	SPRING WG should avoid modification to existing data planes that would		The work in the SPRING WG should avoid modification to existing data
	make them incompatible with existing deployments. Where possible,		planes that would make them incompatible with existing deployments.
	existing control and management plane protocols must be used within		Where possible, existing control and management plane protocols must
	existing architectures to implement the SPRING function. Any		be used within existing architectures to implement the SPRING
	modification of -or extension to- existing architectures, data planes,		function. Any modification of -or extension to- existing
	or control or management plane protocols should be carried out in the		architectures, data planes, or control or management plane protocols
	WGs responsible for the architecture, data plane, or control or		should be carried out in the WGs responsible for the architecture,
	management plane protocol being modified and in coordination with the		data plane, or control or management plane protocol being modified
	SPRING WG, but may be done in SPRING WG after agreement with all the		and in coordination with the SPRING WG, but may be done in SPRING WG
	relevant WG chairs and responsible Area Directors.		after agreement with all the relevant WG chairs and responsible Area
			Directors.
	The SPRING WG defines procedures that allow a node to steer a packet		The SPRING WG defines procedures that allow a node to steer a packet
	through an SR Policy instantiated as an ordered list of instructions		through an SR Policy instantiated as an ordered list of instructions
	called segments and without the need for per-path state information to		called segments without needing per-path state information at transit
	be held at transit nodes. Full explicit control (through loose or strict		nodes. A network comprising only SPRING nodes can achieve full path
	path specification) can be achieved in a network comprising only SPRING		control (through loose or strict path specification). However, SPRING
	nodes, however SPRING nodes must inter-operate through loose routing in		nodes must interoperate through loose routing in existing networks.
	existing networks and may find it advantageous to use loose routing for
	other network applications.
	The scope of the SPRING WG work includes both single Autonomous System
	(AS) and multi-AS environments. Segment Routing typically operates within
	a single trust domain which requires the enforcement of a strict boundary
	and preventing Segment Routing packets from entering the trusted domain
	from the untrusted exterior. Certain deployments may however involve
	multiple trust domains which in turn may imply the use of cross/inter
	domain segments. Risk models associated with these various scenarios may
	necessitate the use of a cryptographic integrity checks to validate that
	the segment list is provided by an authorised entity.
	As is customary in the Routing Area, the SPRING WG will also identify and
	address any other security considerations introduced by the technologies
	it defines; addressing such considerations may require the introduction of
	new functionality in protocols leveraged for Source Routing, in which case
	the SPRING WG will formulate requirements to be considered by the
	appropriate WG for that work. The SPRING WG is however not expected to
	wait on the development of a solution to these requirements before
	progressing its own documents. SPRING technologies may be deployed in
	environments spanning a range of risk and threat models, which may impact
	both the security considerations and the requirements placed on other
	protocols in order to support Source Routing protocols.
	The technologies SPRING WG defines may be applicable to both centralised
	and distributed path computation.
	The SPRING WG will manage its specific work items by milestones agreed
	with the responsible Area Director.
	The work-items of the SPRING WG include functional specifications for:
	o Segment Routing policies and the associated steering, signalling and
	traffic engineering mechanisms.
	o Source-routed stateless service chaining using SR-MPLS and SRv6
	dataplanes.
	o SRv6 network programming for the underlay networks and overlay
	services, and including data plane behavior and functions associated
	with SIDs
	o Operation, Administration and Management (OAM), and traffic accounting
	in networks with SR-MPLS and SRv6 data planes in the case where SR
	introduces specificities compared to MPLS or IPv6 technologies.
	o Performance Management (PM) and monitoring in networks with SR-MPLS
	and SRv6 data planes in the case where SR introduces specificities
	compared to MPLS or IPv6 technologies.
	o Inter-working between SRv6 and SR-MPLS and between SR and existing
	routing solutions to allow for seamless deployment and co-existence.
	o New types of segments mapping to forwarding behaviour (e.g., local
	ingress replication, local forwarding resources, a pre-existing
	replication structure) if needed for new usages.
	Any of the above may require architectural extensions.		By default, Segment Routing operates within a trusted domain and
			requires the enforcement of a strict boundary to prevent Segment
			Routing packets from entering the trusted domain [rfc8402]. Some
			deployments may involve multiple trusted domains and the use of
			cross/inter-domain segments. Documents which deal with such
			situations need to include a risk analysis and use mechanisms to
			validate that the segment list is provided by an authorized entity
			and has not been modified in transit.
	The work-items of SPRING WG also include:		The SPRING WG will manage its specific work items based on WG input
	o Specification of management models (YANG) for Segment Routing		and according to milestones agreed upon with the responsible Area
	applications, services and networks with SR-MPLS and SRv6 dataplanes.		Director.
	The SPRING WG will coordinate and collaborate with other WGs as needed.		The SPRING WG will coordinate and collaborate with other WGs as
	Specific expected interactions include (but may not be limited to):		needed. Specific expected interactions include (but may not be
			limited to):
	mpls on the MPLS dataplane and OAM extensions,		mpls on the MPLS data plane and associated extensions
	6man on the IPv6 dataplane for SR and associated OAM extensions		6man on the IPv6 data plane and associated extensions
	lsr on OSPF and IS-IS extensions to flood SPRING-related information		lsr on OSPF and IS-IS extensions
	idr for BGP extensions		idr on BGP extensions
	bess for VPN control plane		bess on VPN control plane
	pce on extensions to communicate with an external entity to compute		pce on extensions for centralized solutions
	and program SPRING paths		teas on traffic engineering architecture
	teas on generic traffic engineering architecture
	sfc on service chaining applications
	rtgwg on fast-reroute technologies		rtgwg on fast-reroute technologies
			srv6ops on SRv6 operations
End of changes. 8 change blocks.
	87 lines changed or deleted		39 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/