< draft-ietf-ospf-link-overload-10.txt		draft-ietf-ospf-link-overload-11.txt >
	Open Shortest Path First IGP S. Hegde		Open Shortest Path First IGP S. Hegde
	Internet-Draft Juniper Networks, Inc.		Internet-Draft Juniper Networks, Inc.
	Intended status: Standards Track P. Sarkar		Intended status: Standards Track P. Sarkar
	Expires: May 30, 2018 H. Gredler		Expires: July 5, 2018 H. Gredler
	Individual		Individual
	M. Nanduri		M. Nanduri
	ebay Corporation		ebay Corporation
	L. Jalil		L. Jalil
	Verizon		Verizon
	November 26, 2017		January 1, 2018
	OSPF Link Overload		OSPF Link Overload
	draft-ietf-ospf-link-overload-10		draft-ietf-ospf-link-overload-11
	Abstract		Abstract
	When a link is being prepared to be taken out of service, the traffic		When a link is being prepared to be taken out of service, the traffic
	needs to be diverted from both ends of the link. Increasing the		needs to be diverted from both ends of the link. Increasing the
	metric to the highest metric on one side of the link is not		metric to the highest metric on one side of the link is not
	sufficient to divert the traffic flowing in the other direction.		sufficient to divert the traffic flowing in the other direction.
	It is useful for routers in an OSPFv2 or OSPFv3 routing domain to be		It is useful for routers in an OSPFv2 or OSPFv3 routing domain to be
	able to advertise a link as being in an overload state to indicate		able to advertise a link as being in an overload state to indicate
	skipping to change at page 2, line 7 ¶		skipping to change at page 2, line 7 ¶
	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 May 30, 2018.		This Internet-Draft will expire on July 5, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Flooding Scope . . . . . . . . . . . . . . . . . . . . . . . 4		3. Flooding Scope . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Link-Overload sub-TLV . . . . . . . . . . . . . . . . . . . . 4		4. Link-Overload sub-TLV . . . . . . . . . . . . . . . . . . . . 4
	4.1. OSPFv2 Link-overload sub-TLV . . . . . . . . . . . . . . 4		4.1. OSPFv2 Link-overload sub-TLV . . . . . . . . . . . . . . 4
	4.2. Remote IPv4 address sub-TLV . . . . . . . . . . . . . . . 4		4.2. Remote IPv4 Address Sub-TLV . . . . . . . . . . . . . . . 4
	4.3. Local/Remote Interface ID sub-TLV . . . . . . . . . . . . 5		4.3. Local/Remote Interface ID Sub-TLV . . . . . . . . . . . . 5
	4.4. OSPFv3 Link-Overload sub-TLV . . . . . . . . . . . . . . 6		4.4. OSPFv3 Link-Overload sub-TLV . . . . . . . . . . . . . . 6
	5. Elements of procedure . . . . . . . . . . . . . . . . . . . . 6		4.5. BGP-LS Link-overload TLV . . . . . . . . . . . . . . . . 6
	5.1. Point-to-point links . . . . . . . . . . . . . . . . . . 6		4.6. Distinguishing parallel links . . . . . . . . . . . . . . 7
	5.2. Broadcast/NBMA links . . . . . . . . . . . . . . . . . . 7		5. Elements of procedure . . . . . . . . . . . . . . . . . . . . 8
	5.3. Point-to-multipoint links . . . . . . . . . . . . . . . . 7		5.1. Point-to-point links . . . . . . . . . . . . . . . . . . 8
	5.4. Unnumbered interfaces . . . . . . . . . . . . . . . . . . 8		5.2. Broadcast/NBMA links . . . . . . . . . . . . . . . . . . 8
	5.5. Hybrid Broadcast and P2MP interfaces . . . . . . . . . . 8		5.3. Point-to-multipoint links . . . . . . . . . . . . . . . . 9
	6. Backward compatibility . . . . . . . . . . . . . . . . . . . 8		5.4. Unnumbered interfaces . . . . . . . . . . . . . . . . . . 9
	7. Applications . . . . . . . . . . . . . . . . . . . . . . . . 8		5.5. Hybrid Broadcast and P2MP interfaces . . . . . . . . . . 9
	7.1. Pseudowire Services . . . . . . . . . . . . . . . . . . . 8		6. Backward compatibility . . . . . . . . . . . . . . . . . . . 10
	7.2. Controller based Traffic Engineering Deployments . . . . 10		7. Applications . . . . . . . . . . . . . . . . . . . . . . . . 10
	7.3. L3VPN Services and sham-links . . . . . . . . . . . . . . 10		7.1. Pseudowire Services . . . . . . . . . . . . . . . . . . . 10
	7.4. Hub and spoke deployment . . . . . . . . . . . . . . . . 11		7.2. Controller based Traffic Engineering Deployments . . . . 11
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 11		7.3. L3VPN Services and sham-links . . . . . . . . . . . . . . 12
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		7.4. Hub and spoke deployment . . . . . . . . . . . . . . . . 13
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	11.1. Normative References . . . . . . . . . . . . . . . . . . 12		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	11.2. Informative References . . . . . . . . . . . . . . . . . 12		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
			11.1. Normative References . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		11.2. Informative References . . . . . . . . . . . . . . . . . 14
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	When a node is being prepared for a planned maintenance or upgrade,		When a node is being prepared for a planned maintenance or upgrade,
	[RFC6987] provides mechanisms to advertise the node being in an		[RFC6987] provides mechanisms to advertise the node being in an
	overload state by setting all outgoing link costs to MaxLinkMetric		overload state by setting all outgoing link costs to MaxLinkMetric
	(0xffff). These procedures are specific to the maintenance activity		(0xffff). These procedures are specific to the maintenance activity
	on a node and cannot be used when a single link on the node requires		on a node and cannot be used when a single link on the node requires
	maintenance.		maintenance.
	skipping to change at page 4, line 34 ¶		skipping to change at page 4, line 37 ¶
	Opaque LSA as defined in [RFC7684].		Opaque LSA as defined in [RFC7684].
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Link-Overload sub-TLV for OSPFv2		Figure 1: Link-Overload sub-TLV for OSPFv2
	Type : TBA (suggested value 5)		Type : TBA (suggested value 7)
	Length: 0		Length: 0
	4.2. Remote IPv4 address sub-TLV		4.2. Remote IPv4 Address Sub-TLV
	This sub-TLV specifies the IPv4 address of remote endpoint on the		This sub-TLV specifies the IPv4 address of remote endpoint on the
	link. It is advertised in the Extended Link TLV as defined in		link. It is advertised in the Extended Link TLV as defined in
	[RFC7684]. This sub-TLV is optional and MAY be advertised in area-		[RFC7684]. This sub-TLV is optional and MAY be advertised in area-
	scoped Extended Link Opaque LSA to identify the link when there are		scoped Extended Link Opaque LSA to identify the link when there are
	multiple parallel links between two nodes.		multiple parallel links between two nodes.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Remote IPv4 address |		| Remote IPv4 address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: Remote IPv4 address sub-TLV		Figure 2: Remote IPv4 Address Sub-TLV
	Type : TBA (suggested value 4)		Type : TBA (suggested value 8)
	Length: 4		Length: 4
	Value: Remote IPv4 address. The remote IP4 address is used to		Value: Remote IPv4 address. The remote IP4 address is used to
	identify the particular link when there are multiple parallel links		identify the particular link when there are multiple parallel links
	between two nodes.		between two nodes.
	4.3. Local/Remote Interface ID sub-TLV		4.3. Local/Remote Interface ID Sub-TLV
	This sub-TLV specifies local and remote interface identifiers. It is		This sub-TLV specifies local and remote interface identifiers. It is
	advertised in the Extended Link TLV as defined in [RFC7684]. This		advertised in the Extended Link TLV as defined in [RFC7684]. This
	sub-TLV is optional and MAY be advertised in area-scoped Extended		sub-TLV is optional and MAY be advertised in area-scoped Extended
	Link Opaque LSA to identify the link when there are multiple parallel		Link Opaque LSA to identify the link when there are multiple parallel
	unnumbered links between two nodes. The local interface-id is		unnumbered links between two nodes. The local interface-id is
	generally readily available. One of the mechanisms to obtain remote		generally readily available. One of the mechanisms to obtain remote
	interface-id is described in [RFC4203].		interface-id is described in [RFC4203].
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Local Interface ID |		| Local Interface ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Remote Interface ID |		| Remote Interface ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: Local/Remote Interface ID sub-TLV		Figure 3: Local/Remote Interface ID Sub-TLV
	Type : TBA (suggested value 11)		Type : TBA (suggested value 9)
	Length: 8		Length: 8
	Value: 4 octets of Local Interface ID followed by 4 octets of Remote		Value: 4 octets of Local Interface ID followed by 4 octets of Remote
	interface ID.		interface ID.
	4.4. OSPFv3 Link-Overload sub-TLV		4.4. OSPFv3 Link-Overload sub-TLV
	The Link Overload sub-TLV is carried in the Router-Link TLV as		The Link Overload sub-TLV is carried in the Router-Link TLV as
	defined in the [I-D.ietf-ospf-ospfv3-lsa-extend] for OSPFv3. The		defined in the [I-D.ietf-ospf-ospfv3-lsa-extend] for OSPFv3. The
	Router-Link TLV contains the neighbour interface-id and can uniquely		Router-Link TLV contains the neighbour interface-id and can uniquely
	identify the link on the remote node.		identify the link on the remote node.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4: Link-Overload sub-TLV for OSPFv3		Figure 4: Link-Overload sub-TLV for OSPFv3
	Type : TBA (Suggested value 4)		Type : TBA (Suggested value 7)
	Length: 0		Length: 0
			4.5. BGP-LS Link-overload TLV
			BGP-LS as defined in [RFC7752] is a mechanism to distribute network
			information to external entities using BGP routing protocol. link-
			overload is an imporatant link information that the external entities
			can use for various usecases as defined in Section 7. BGP Link NLRI
			is used to carry the link information. a new TLV called Link-
			Overload is defined to describe the link attribute corresponding to
			link-overload state.
			4.6. Distinguishing parallel links
			++++++++++I.w I.y +++++++++
			|Router A|------------------|Router B |
			| |------------------| |
			++++++++++I.x I.z++++++++++
			Figure 5: Parallel Linkls
			Consider two routers A and B connected with two parallel point-to-
			point interfaces. I.w and I.x represent the Interface address on
			Router A's side and I.y and I.z represent Interface addresses on
			Router B's side. The extended link opaque LSA as described in
			[RFC7684] describes links using link-type, Link-ID and Link-data.
			For ex. Link with address I.w is described as below on Router A.
			Link-type = Point-to-point
			Link-ID: Router-ID B
			Link-Data = I.w
			A third node (controller or head-end) in the network cannot
			distinguish the Interface on router B which is connected to this
			particular Interface with the above information. Interface with
			address I.y or I.z could be chosen due to this ambiguity. In such
			cases Remote-IPv4 Address sub-TLV should be originated and added to
			the extended link-TLV. The usecases as described in Section 7
			require controller or head-end nodes to interpret the link-overload
			information and hence the need for the RemoteIPv4 address sub-TLV.
			I.y is carried in the extended-link-TLV which unambiguously
			identifies the interface on the remote side. OSPFv3 Router-link-TLV
			as described in [I-D.ietf-ospf-ospfv3-lsa-extend] contains Interface
			ID and neighbor's Interface-ID which can uniquely identify connecting
			interface on the remote side and hence OSPFv3 does not require
			seperate Remote-IPv6 address to be advertised along with OSPFv2-link-
			overload-sub-TLV.
	5. Elements of procedure		5. Elements of procedure
	The Link-Overload sub-TLV indicates that the link identified by the		As defined in [RFC7684] every link on the node will have a separate
	sub-TLV is overloaded. The node that has the link to be taken out of		Extended Link Opaque LSA. The node that has the link to be taken out
	service SHOULD advertise the Link-Overload sub-TLV in the Extended		of service SHOULD advertise the Link-Overload sub-TLV in the Extended
	Link TLV of the Extended Link Opaque LSA as defined in [RFC7684] for		Link TLV of the Extended Link Opaque LSA as defined in [RFC7684] for
	OSPFv2. The Link-Overload information is advertised as a property of		OSPFv2. The Link-Overload sub-TLV indicates that the link identified
	the link and is flooded across the area. This information can be		by the sub-TLV is overloaded. The Link-Overload information is
	used by ingress routers or controllers to take special actions. An		advertised as a property of the link and is flooded across the area.
	application specific to this use case is described in Section 7.2.		This information can be used by ingress routers or controllers to
			take special actions. An application specific to this use case is
			described in Section 7.2.
	The precise action taken by the remote node at the other end of the		The precise action taken by the remote node at the other end of the
	link identified as overloaded depends on the link type.		link identified as overloaded depends on the link type.
	5.1. Point-to-point links		5.1. Point-to-point links
	The node that has the link to be taken out of service MUST set metric		The node that has the link to be taken out of service MUST set metric
	of the link to MaxLinkMetric (0xffff) and re-originate its router-		of the link to MaxLinkMetric (0xffff) and re-originate its router-
	LSA. The TE metric SHOULD be set to MAX-TE-METRIC (0xfffffffe) and		LSA. The TE metric SHOULD be set to MAX-TE-METRIC (0xfffffffe) and
	the node SHOULD re-originate the corresponding TE Link Opaque LSAs.		the node SHOULD re-originate the corresponding TE Link Opaque LSAs.
	skipping to change at page 9, line 35 ¶		skipping to change at page 11, line 22 ¶
	CE1---------PE1----------PE2---------CE2		CE1---------PE1----------PE2---------CE2
	| \		| \
	| \		| \
	| ------CE4		| ------CE4
	| |		| |
	| |		| |
	| |		| |
	=================================		=================================
	Private VLAN		Private VLAN
	Figure 5: Pseudowire Services		Figure 6: Pseudowire Services
	In the example shown in Figure 5, when the PE1 node is going out of		In the example shown in Figure 6, when the PE1 node is going out of
	service for maintenance, service providers set the PE1 to overload		service for maintenance, service providers set the PE1 to overload
	state. The PE1 going in to overload state triggers all the CEs		state. The PE1 going in to overload state triggers all the CEs
	connected to the PE (CE1 in this case) to set their pseudowire links		connected to the PE (CE1 in this case) to set their pseudowire links
	passing via PE1 to link-overload state. The mechanisms used to		passing via PE1 to link-overload state. The mechanisms used to
	communicate between PE1 and CE1 is outside the scope of this		communicate between PE1 and CE1 is outside the scope of this
	document. CE1 sets the link-overload state on its private VLAN		document. CE1 sets the link-overload state on its private VLAN
	connecting CE3, CE2 and CE4 and changes the metric to MAX_METRIC and		connecting CE3, CE2 and CE4 and changes the metric to MAX_METRIC and
	re-originates the corresponding LSA. The remote end of the link at		re-originates the corresponding LSA. The remote end of the link at
	CE3, CE2, and CE4 also set the metric on the link to MaxLinkMetric		CE3, CE2, and CE4 also set the metric on the link to MaxLinkMetric
	and the traffic from both directions gets diverted away from the		and the traffic from both directions gets diverted away from the
	skipping to change at page 10, line 34 ¶		skipping to change at page 12, line 18 ¶
	| |____________ | |		| |____________ | |
	| |		| |
	|--------- Primary Path ------------------|		|--------- Primary Path ------------------|
	PE1---------P1----------------P2---------PE2		PE1---------P1----------------P2---------PE2
	| |		| |
	| |		| |
	|________P3________|		|________P3________|
	Alternate Path		Alternate Path
	Figure 6: Controller based Traffic Engineering		Figure 7: Controller based Traffic Engineering
	In the above example, PE1->PE2 LSP is set-up to satisfy a constraint		In the above example, PE1->PE2 LSP is set-up to satisfy a constraint
	of 10 Gbps bandwidth on each link. The links P1->P3 and P3->P2 have		of 10 Gbps bandwidth on each link. The links P1->P3 and P3->P2 have
	only 1 Gbps capacity and there is no alternate path satisfying the		only 1 Gbps capacity and there is no alternate path satisfying the
	bandwidth constraint of 10Gbps. When P1->P2 link is being prepared		bandwidth constraint of 10Gbps. When P1->P2 link is being prepared
	for maintenance, the controller receives the link-overload		for maintenance, the controller receives the link-overload
	information, as there is no alternate path available which satisfies		information, as there is no alternate path available which satisfies
	the constraints, the controller chooses a path that is less optimal		the constraints, the controller chooses a path that is less optimal
	and temporarily sets up an alternate path via P1->P3->P2. Once the		and temporarily sets up an alternate path via P1->P3->P2. Once the
	traffic is diverted, the P1->P2 link can be taken out of service for		traffic is diverted, the P1->P2 link can be taken out of service for
	skipping to change at page 11, line 39 ¶		skipping to change at page 13, line 27 ¶
	8. Security Considerations		8. Security Considerations
	This document does not introduce any further security issues other		This document does not introduce any further security issues other
	than those discussed in [RFC2328] and [RFC5340].		than those discussed in [RFC2328] and [RFC5340].
	9. IANA Considerations		9. IANA Considerations
	This specification updates one OSPF registry:		This specification updates one OSPF registry:
	OSPF Extended Link TLVs Registry		OSPFv2 Extended Link TLV Sub-TLVs
	i) Link-Overload sub-TLV - Suggested value 5		i) Link-Overload Sub-TLV - Suggested value 7
	ii) Remote IPv4 address sub-TLV - Suggested value 4		ii) Remote IPv4 Address Sub-TLV - Suggested value 8
	iii) Local/Remote Interface ID sub-TLV - Suggested Value 11		iii) Local/Remote Interface ID Sub-TLV - Suggested Value 9
	OSPFV3 Router Link TLV Registry		OSPFv3 Extended-LSA sub-TLV Registry
	i) Link-Overload sub-TLV - suggested value 4		i) Link-Overload sub-TLV - suggested value 7
	BGP-LS Link NLRI Registry [RFC7752]		BGP-LS Link NLRI Registry [RFC7752]
	i)Link-Overload TLV - Suggested 1101		i)Link-Overload TLV - Suggested 1101
	10. Acknowledgements		10. Acknowledgements
	Thanks to Chris Bowers for valuable inputs and edits to the document.		Thanks to Chris Bowers for valuable inputs and edits to the document.
	Thanks to Jeffrey Zhang, Acee Lindem and Ketan Talaulikar for inputs.		Thanks to Jeffrey Zhang, Acee Lindem and Ketan Talaulikar for inputs.
	Thanks to Karsten Thomann for careful review and inputs on the		Thanks to Karsten Thomann for careful review and inputs on the
	applications where link-overload is useful.		applications where link-overload is useful.
	11. References		11. References
End of changes. 29 change blocks.
	51 lines changed or deleted		104 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/