rfc9830v2.txt		rfc9830.txt
	skipping to change at line 155 ¶		skipping to change at line 155 ¶
	the CPs of an SR Policy to the headend of that SR Policy. The		the CPs of an SR Policy to the headend of that SR Policy. The
	document describes the functionality provided by BGP and, as		document describes the functionality provided by BGP and, as
	appropriate, provides references for the functionality, which is		appropriate, provides references for the functionality, which is
	outside the scope of BGP (i.e., resides within SRPM on the headend		outside the scope of BGP (i.e., resides within SRPM on the headend
	node).		node).
	This document specifies a way of representing SR Policy CPs in BGP		This document specifies a way of representing SR Policy CPs in BGP
	UPDATE messages. BGP can then be used to propagate the SR Policy CPs		UPDATE messages. BGP can then be used to propagate the SR Policy CPs
	to the headend nodes in a network. The usual BGP rules for BGP		to the headend nodes in a network. The usual BGP rules for BGP
	propagation and best-path selection are used. At the headend of a		propagation and best-path selection are used. At the headend of a
	specific policy, this will result in one or more CPs being installed		specific SR Policy, this will result in one or more CPs being
	into the "BGP table". These paths are then passed to the SRPM. The		installed into the "BGP table". These paths are then passed to the
	SRPM may compare them to CPs learned via other mechanisms and will		SRPM. The SRPM may compare them to CPs learned via other mechanisms
	choose one or more paths to be installed in the data plane. BGP		and will choose one or more paths to be installed in the data plane.
	itself does not install SR Policy CPs into the data plane.		BGP itself does not install SR Policy CPs into the data plane.
	This document introduces a BGP Subsequent Address Family Identifier		This document introduces a BGP Subsequent Address Family Identifier
	(SAFI) for IPv4 and IPv6 address families. In BGP UPDATE messages of		(SAFI) for IPv4 and IPv6 address families. In BGP UPDATE messages of
	those AFI/SAFIs, the Network Layer Reachability Information (NLRI)		those AFI/SAFIs, the Network Layer Reachability Information (NLRI)
	identifies an SR Policy CP while the attributes encode the segment		identifies an SR Policy CP while the attributes encode the segment
	lists and other details of that SR Policy CP.		lists and other details of that SR Policy CP.
	While, for simplicity, the text in this document states that BGP		While, for simplicity, the text in this document states that BGP
	advertises an SR Policy, it is to be understood that BGP advertises a		advertises an SR Policy, it is to be understood that BGP advertises a
	CP of an SR Policy and that this SR Policy might have several other		CP of an SR Policy and that this SR Policy might have several other
	CPs provided via BGP (via an NLRI with a different distinguisher as		CPs provided via BGP (via an NLRI with a different distinguisher as
	defined in Section 2.1), PCEP, NETCONF, or local policy		defined in Section 2.1), PCEP, NETCONF, or local policy
	configuration.		configuration.
	Typically, an SR Policy Controller [RFC9256] defines the set of		Typically, an SR Policy Controller [RFC9256] defines the set of
	policies and advertises them to policy headend routers (typically		policies and advertises them to SR Policy headend routers (typically
	ingress routers). These policy advertisements use the BGP extensions		ingress routers). These SR Policy advertisements use the BGP
	defined in this document. In most cases, the policy advertisement is		extensions defined in this document. In most cases, the SR Policy
	tailored for a specific policy headend; consequently, it may be		advertisement is tailored for a specific SR Policy headend;
	transmitted over a direct BGP session (i.e., without intermediate BGP		consequently, it may be transmitted over a direct BGP session (i.e.,
	hops) to that headend and is not propagated any further. In such		without intermediate BGP hops) to that headend and is not propagated
	cases, the policy advertisements will not traverse any Route		any further. In such cases, the SR Policy advertisements will not
	Reflector (RR) (see [RFC4456] and Section 4.2.3).		traverse any Route Reflector (RR) (see [RFC4456] and Section 4.2.3).
	Alternatively, a BGP egress router may advertise SR Policies that		Alternatively, a BGP egress router may advertise SR Policies that
	represent paths that terminate on it. In such cases, the router can		represent paths that terminate on it. In such cases, the router can
	send these policies directly to each headend over a dedicated BGP		send these policies directly to each headend over a dedicated BGP
	session, without necessitating any further propagation of the policy.		session, without necessitating any further propagation of the SR
			Policy.
	In some situations, it is undesirable for a controller or BGP egress		In some situations, it is undesirable for a controller or BGP egress
	router to have a BGP session to each policy headend. In these		router to have a BGP session to each SR Policy headend. In these
	situations, BGP RRs may be used to propagate the advertisements. In		situations, BGP RRs may be used to propagate the advertisements. In
	certain other deployments, it may be necessary for the advertisement		certain other deployments, it may be necessary for the advertisement
	to propagate through a sequence of one or more Autonomous Systems		to propagate through a sequence of one or more Autonomous Systems
	(ASes) within an SR Domain (refer to Section 7 for the associated		(ASes) within an SR Domain (refer to Section 7 for the associated
	security considerations). To make this possible, an attribute needs		security considerations). To make this possible, an attribute needs
	to be attached to the advertisement that enables a BGP speaker to		to be attached to the advertisement that enables a BGP speaker to
	determine whether it is intended to be a headend for the advertised		determine whether it is intended to be a headend for the advertised
	policy. This is done by attaching one or more Route Target extended		SR Policy. This is done by attaching one or more Route Target
	communities to the advertisement [RFC4360].		extended communities to the advertisement [RFC4360].
	The BGP extensions for the advertisement of SR Policies include		The BGP extensions for the advertisement of SR Policies include
	following components:		following components:
	* A SAFI whose NLRIs identify an SR Policy CP.		* A SAFI whose NLRIs identify an SR Policy CP.
	* A Tunnel Type identifier for SR Policy and a set of sub-TLVs to be		* A Tunnel Type identifier for SR Policy and a set of sub-TLVs to be
	inserted into the Tunnel Encapsulation Attribute (as defined in		inserted into the Tunnel Encapsulation Attribute (as defined in
	[RFC9012]) specifying segment lists of the SR Policy CP as well as		[RFC9012]) specifying segment lists of the SR Policy CP as well as
	other information about the SR Policy.		other information about the SR Policy.
	skipping to change at line 275 ¶		skipping to change at line 276 ¶
	+------------------+		+------------------+
	Figure 1: SR Policy SAFI Format		Figure 1: SR Policy SAFI Format
	Where:		Where:
	NLRI Length: 1 octet indicating the length expressed in bits as		NLRI Length: 1 octet indicating the length expressed in bits as
	defined in [RFC4760]. When AFI = 1, the value MUST be 96; when		defined in [RFC4760]. When AFI = 1, the value MUST be 96; when
	AFI = 2, the value MUST be 192.		AFI = 2, the value MUST be 192.
	Distinguisher: 4-octet value uniquely identifying the policy in the		Distinguisher: 4-octet value uniquely identifying the SR Policy in
	context of <Color, Endpoint> tuple. The distinguisher has no		the context of <Color, Endpoint> tuple. The distinguisher has no
	semantic value. It is used by the SR Policy originator to form		semantic value. It is used by the SR Policy originator to form
	unique NLRIs the following situations:		unique NLRIs the following situations:
	* to differentiate multiple CPs of the same SR Policy		* to differentiate multiple CPs of the same SR Policy
	* to differentiate CPs meant for different headends but having		* to differentiate CPs meant for different headends but having
	the same Color and Endpoint		the same Color and Endpoint
	The distinguisher is the discriminator of the SR Policy CP as		The distinguisher is the discriminator of the SR Policy CP as
	specified in Section 2.5 of [RFC9256].		specified in Section 2.5 of [RFC9256].
	Policy Color: 4 octets that carry an unsigned non-zero integer value		Policy Color: 4 octets that carry an unsigned non-zero integer value
	indicating the Color of the SR Policy as specified in Section 2.1		indicating the Color of the SR Policy as specified in Section 2.1
	of [RFC9256]. The Color is used to match the Color of the		of [RFC9256]. The Color is used to match the Color of the
	destination prefixes to steer traffic into the SR Policy as		destination prefixes to steer traffic into the SR Policy as
	specified in Section 8 of [RFC9256].		specified in Section 8 of [RFC9256].
	Endpoint: a value that identifies the Endpoint of a policy. The		Endpoint: a value that identifies the Endpoint of an SR Policy. The
	Endpoint may represent a single node or a set of nodes (e.g., an		Endpoint may represent a single node or a set of nodes (e.g., an
	anycast address). The Endpoint is an IPv4 (4-octet) address or an		anycast address). The Endpoint is an IPv4 (4-octet) address or an
	IPv6 (16-octet) address according to the AFI of the NLRI. The		IPv6 (16-octet) address according to the AFI of the NLRI. The
	address can be either unicast or an unspecified address (0.0.0.0		address can be either unicast or an unspecified address (0.0.0.0
	for IPv4, :: for IPv6), known as a null Endpoint as specified in		for IPv4, :: for IPv6), known as a null Endpoint as specified in
	Section 2.1 of [RFC9256].		Section 2.1 of [RFC9256].
	The Color and Endpoint are used to automate the steering of BGP		The Color and Endpoint are used to automate the steering of BGP
	service routes on an SR Policy as described in Section 8 of		service routes on an SR Policy as described in Section 8 of
	[RFC9256].		[RFC9256].
	skipping to change at line 561 ¶		skipping to change at line 562 ¶
	* The S-Flag encodes the "Specified-BSID-Only" behavior. It is		* The S-Flag encodes the "Specified-BSID-Only" behavior. It is
	used by SRPM as described in Section 6.2.3 of [RFC9256].		used by SRPM as described in Section 6.2.3 of [RFC9256].
	* The I-Flag encodes the "Drop-Upon-Invalid" behavior. It is		* The I-Flag encodes the "Drop-Upon-Invalid" behavior. It is
	used by SRPM as described in Section 8.2 of [RFC9256] to define		used by SRPM as described in Section 8.2 of [RFC9256] to define
	a specific SR Policy forwarding behavior. The flag indicates		a specific SR Policy forwarding behavior. The flag indicates
	that the SR Policy is to perform the "Drop-Upon-Invalid"		that the SR Policy is to perform the "Drop-Upon-Invalid"
	behavior when no valid CP is available for this SR Policy. In		behavior when no valid CP is available for this SR Policy. In
	this situation, the CP with the highest preference amongst		this situation, the CP with the highest preference amongst
	those with the "Drop-Upon-Invalid" config is made active to		those with the "Drop-Upon-Invalid" behavior is made active to
	drop traffic steered over the SR Policy.		drop traffic steered over the SR Policy.
	* The unassigned bits in the Flags field MUST be set to zero upon		* The unassigned bits in the Flags field MUST be set to zero upon
	transmission and MUST be ignored upon receipt.		transmission and MUST be ignored upon receipt.
	RESERVED: 1 octet of reserved bits. MUST be set to zero on		RESERVED: 1 octet of reserved bits. MUST be set to zero on
	transmission and MUST be ignored on receipt.		transmission and MUST be ignored on receipt.
	Binding SID: If the length is 2, then no BSID is present. If the		Binding SID: If the length is 2, then no BSID is present. If the
	length is 6, then the BSID is encoded in 4 octets using the format		length is 6, then the BSID is encoded in 4 octets using the format
	skipping to change at line 775 ¶		skipping to change at line 776 ¶
	Type A: SR-MPLS Label		Type A: SR-MPLS Label
	Type B: SRv6 SID		Type B: SRv6 SID
	Type C: IPv4 Prefix with optional SR Algorithm		Type C: IPv4 Prefix with optional SR Algorithm
	Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS		Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS
	Type E: IPv4 Prefix with Local Interface ID		Type E: IPv4 Prefix with Local Interface ID
	Type F: IPv4 Addresses for link Endpoints as Local, Remote pair		Type F: IPv4 Addresses for link endpoints as Local, Remote pair
	Type G: IPv6 Prefix and Interface ID for link Endpoints as Local,		Type G: IPv6 Prefix and Interface ID for link endpoints as Local,
	Remote pair for SR-MPLS		Remote pair for SR-MPLS
	Type H: IPv6 Addresses for link Endpoints as Local, Remote pair for		Type H: IPv6 Addresses for link endpoints as Local, Remote pair for
	SR-MPLS		SR-MPLS
	Type I: IPv6 Global Prefix with optional SR Algorithm for SRv6		Type I: IPv6 Global Prefix with optional SR Algorithm for SRv6
	Type J: IPv6 Prefix and Interface ID for link Endpoints as Local,		Type J: IPv6 Prefix and Interface ID for link endpoints as Local,
	Remote pair for SRv6		Remote pair for SRv6
	Type K: IPv6 Addresses for link Endpoints as Local, Remote pair for		Type K: IPv6 Addresses for link endpoints as Local, Remote pair for
	SRv6		SRv6
	The following subsections specify the sub-TLVs used for Segment Types		The following subsections specify the sub-TLVs used for Segment Types
	A and B. The other segment types are specified in [RFC9831]. As		A and B. The other segment types are specified in [RFC9831]. As
	specified in Section 5.1 of [RFC9256], a mix of SR-MPLS and SRv6		specified in Section 5.1 of [RFC9256], a mix of SR-MPLS and SRv6
	segments make the segment-list invalid.		segments make the segment-list invalid.
	2.4.4.2.1. Segment Type A		2.4.4.2.1. Segment Type A
	The Type A Segment sub-TLV encodes a single SR-MPLS SID. The format		The Type A Segment sub-TLV encodes a single SR-MPLS SID. The format
	skipping to change at line 1355 ¶		skipping to change at line 1356 ¶
	This section describes the error-handling actions, as described in		This section describes the error-handling actions, as described in
	[RFC7606], that are to be performed for the handling of the BGP		[RFC7606], that are to be performed for the handling of the BGP
	UPDATE messages for the BGP SR Policy SAFI.		UPDATE messages for the BGP SR Policy SAFI.
	A BGP speaker MUST perform the following syntactic validation of the		A BGP speaker MUST perform the following syntactic validation of the
	SR Policy NLRI to determine if it is malformed. This includes the		SR Policy NLRI to determine if it is malformed. This includes the
	validation of the length of each NLRI and the total length of the		validation of the length of each NLRI and the total length of the
	MP_REACH_NLRI and MP_UNREACH_NLRI attributes. It also includes the		MP_REACH_NLRI and MP_UNREACH_NLRI attributes. It also includes the
	validation of the consistency of the NLRI length with the AFI and the		validation of the consistency of the NLRI length with the AFI and the
	Endpoint address as specified in Section 2.1.		endpoint address as specified in Section 2.1.
	When the error determined allows for the router to skip the malformed		When the error determined allows for the router to skip the malformed
	NLRI(s) and continue the processing of the rest of the BGP UPDATE		NLRI(s) and continue the processing of the rest of the BGP UPDATE
	message, then it MUST handle such malformed NLRIs as 'treat-as-		message, then it MUST handle such malformed NLRIs as 'treat-as-
	withdraw'. In other cases, where the error in the NLRI encoding		withdraw'. In other cases, where the error in the NLRI encoding
	results in the inability to process the BGP UPDATE message (e.g.,		results in the inability to process the BGP UPDATE message (e.g.,
	length-related encoding errors), then the router SHOULD handle such		length-related encoding errors), then the router SHOULD handle such
	malformed NLRIs as "AFI/SAFI disable" when other AFI/SAFIs besides SR		malformed NLRIs as "AFI/SAFI disable" when other AFI/SAFIs besides SR
	Policy are being advertised over the same session. Alternately, the		Policy are being advertised over the same session. Alternately, the
	router MUST perform "session reset" when the session is only being		router MUST perform "session reset" when the session is only being
End of changes. 14 change blocks.
	27 lines changed or deleted		28 lines changed or added
This html diff was produced by rfcdiff 1.48.