Diff: rfc9929.original

	rfc9929.original	rfc9929.txt


	Networking Working Group P. Psenak, Ed.	Internet Engineering Task Force (IETF) P. Psenak, Ed.
	Internet-Draft C. Filsfils	Request for Comments: 9929 C. Filsfils
	Intended status: Standards Track D. Voyer	Category: Standards Track D. Voyer
	Expires: 29 March 2026 Cisco Systems	ISSN: 2070-1721 Cisco Systems
	S. Hegde	S. Hegde
	Juniper Networks, Inc.	Juniper Networks, Inc.
	G. Mishra	G. Mishra
	Verizon Inc.	Verizon Inc.

	25 September 2025	February 2026

	IGP Unreachable Prefix Announcement	IGP Unreachable Prefix Announcement

	draft-ietf-lsr-igp-ureach-prefix-announce-11

	Abstract	Abstract

	Summarization is often used in multi-area or multi-domain networks to	Summarization is often used in multi-area or multi-domain networks to
	improve network efficiency and scalability. With summarization in	improve network efficiency and scalability. With summarization in
	place, there is a need to signal loss of reachability to an	place, there is a need to signal loss of reachability to an
	individual prefix covered by the summary. This enables fast	individual prefix covered by the summary. This enables fast

	convergence by steering traffic, when aplicable, away from the node	convergence by steering traffic, when applicable, away from the node
	which owns the prefix and is no longer reachable.	which owns the prefix and is no longer reachable.

	This document specifies protocol mechanisms in IS-IS and OSPF,	This document specifies protocol mechanisms in IS-IS and OSPF,
	together with two new flags, to advertise such prefix reachability	together with two new flags, to advertise such prefix reachability
	loss.	loss.


	The term OSPF in this document is used to refer to both OSPFv2 and	The term "OSPF" in this document is used to refer to both OSPFv2 and
	OSPFv3.	OSPFv3.


	Requirements Language

	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119][RFC8174] when, and only when, they appear in all
	capitals, as shown here.

	Status of This Memo	Status of This Memo


	This Internet-Draft is submitted in full conformance with the	This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.

	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.


	Internet-Drafts are draft documents valid for a maximum of six months	This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any	(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference	received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."	Internet Engineering Steering Group (IESG). Further information on
		Internet Standards is available in Section 2 of RFC 7841.


	This Internet-Draft will expire on 29 March 2026.	Information about the current status of this document, any errata,
		and how to provide feedback on it may be obtained at
		https://www.rfc-editor.org/info/rfc9929.

	Copyright Notice	Copyright Notice


	Copyright (c) 2025 IETF Trust and the persons identified as the	Copyright (c) 2026 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 (https://trustee.ietf.org/	Provisions Relating to IETF Documents
	license-info) in effect on the date of publication of this document.	(https://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights	publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components	carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Revised BSD License text as	to this document. Code Components extracted from this document must
	described in Section 4.e of the Trust Legal Provisions and are	include Revised BSD License text as described in Section 4.e of the
	provided without warranty as described in the Revised BSD License.	Trust Legal Provisions and are provided without warranty as described
		in the Revised BSD License.

	Table of Contents	Table of Contents


	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3	1. Introduction
	2. Generation of the UPA . . . . . . . . . . . . . . . . . . . . 4	1.1. Requirements Language
	3. Supporting UPA in IS-IS . . . . . . . . . . . . . . . . . . . 6	2. Generation of the UPA
	3.1. Advertisement of UPA in IS-IS . . . . . . . . . . . . . . 6	3. Supporting UPA in IS-IS
	3.2. Signaling UPA in IS-IS . . . . . . . . . . . . . . . . . 7	3.1. Advertisement of UPA in IS-IS
	3.3. Propagation of UPA in IS-IS . . . . . . . . . . . . . . . 8	3.2. Signaling UPA in IS-IS
	4. Supporting UPA in OSPF . . . . . . . . . . . . . . . . . . . 8	3.3. Propagation of UPA in IS-IS
	4.1. Advertisement of UPA in OSPF . . . . . . . . . . . . . . 9	4. Supporting UPA in OSPF
	4.2. Signaling UPA in OSPF . . . . . . . . . . . . . . . . . . 9	4.1. Advertisement of UPA in OSPF
	4.2.1. Signaling UPA in OSPFv2 . . . . . . . . . . . . . . . 10	4.2. Signaling UPA in OSPF
	4.2.2. Signaling UPA in OSPFv3 . . . . . . . . . . . . . . . 10	4.2.1. Signaling UPA in OSPFv2
	4.3. Propagation of UPA in OSPF . . . . . . . . . . . . . . . 11	4.2.2. Signaling UPA in OSPFv3
	5. Processing of the UPA . . . . . . . . . . . . . . . . . . . . 11	4.3. Propagation of UPA in OSPF
	6. Area and Domain Partition . . . . . . . . . . . . . . . . . . 11	5. Processing of the UPA
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12	6. Area and Domain Partition
	7.1. IS-IS Prefix Attribute Flags Sub-TLV . . . . . . . . . . 12	7. IANA Considerations
	7.2. OSPFv2 and OSPFv3 OSPFv2 Prefix Extended Flags . . . . . 12	7.1. IS-IS Prefix Attribute Flags Sub-TLV
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 12	7.2. OSPFv2 and OSPFv3 Prefix Extended Flags
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13	8. Security Considerations
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13	9. References
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13	9.1. Normative References
	11.1. Normative References . . . . . . . . . . . . . . . . . . 13	9.2. Informative References
	11.2. Informative References . . . . . . . . . . . . . . . . . 16	Acknowledgements
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16	Contributors
		Authors' Addresses

	1. Introduction	1. Introduction


	Link-state Interior Gateway Protocols (IGPs) protocols like	Link-state Interior Gateway Protocols (IGPs) like Intermediate System
	Intermediate System to Intermediate System (IS-IS) [ISO10589], Open	to Intermediate System (IS-IS) [ISO10589], Open Shortest Path First
	Shortest Path First version 2 (OSPFv2)) [RFC2328], and Open Shortest	version 2 (OSPFv2)) [RFC2328], and Open Shortest Path First version 3
	Path First version 3 (OSPFv3) [RFC5340] are primarily used to	(OSPFv3) [RFC5340] are primarily used to distribute routing
	distribute routing information between routers belonging to a single	information between routers belonging to a single Autonomous System
	Autonomous System (AS) and to calculate the reachability for IPv4 or	(AS) and to calculate the reachability for IPv4 or IPv6 prefixes
	IPv6 prefixes advertised by the individual nodes inside the AS. Each	advertised by the individual nodes inside the AS. Each node
	node advertises the state of its local adjacencies, connected	advertises the state of its local adjacencies, connected prefixes,
	prefixes, capabilities, etc. The collection of these states from all	capabilities, etc. The collection of these states from all the
	the routers inside the area form a link-state database (LSDB) that	routers inside the area form a Link State Database (LSDB) that
	describes the topology of the area and holds additional state	describes the topology of the area and holds additional state
	information about the prefixes, router capabilities, etc.	information about the prefixes, router capabilities, etc.

	The growth of networks running a link-state routing protocol results	The growth of networks running a link-state routing protocol results

	in the addition of more state which leads to scalability and	in the addition of more state, which leads to scalability and
	convergence challenges. The organization of networks into levels/	convergence challenges. The organization of networks into levels/
	areas and IGP domains helps limit the scope of link-state information	areas and IGP domains helps limit the scope of link-state information
	within certain boundaries. However, the state related to prefix	within certain boundaries. However, the state related to prefix
	reachability often requires propagation across a multi-area/level	reachability often requires propagation across a multi-area/level
	and/or multi-domain IGP network. IGP summarization is a network	and/or multi-domain IGP network. IGP summarization is a network
	engineering technique for combining multiple smaller, contiguous IP	engineering technique for combining multiple smaller, contiguous IP
	networks into a single, larger summary route. Techniques such as	networks into a single, larger summary route. Techniques such as

	summarization have been used traditionally to address the scale	summarization have been used traditionally to address the scaling
	challenges associated with advertising prefix state outside of the	challenges associated with advertising prefix state outside of the
	local area/domain. However, this results in suppression of the	local area/domain. However, this results in suppression of the
	individual prefix state that is useful for triggering fast-	individual prefix state that is useful for triggering fast-

	convergence mechanisms outside of the IGPs - e.g., Border Gateway	convergence mechanisms outside of the IGPs -- e.g., Border Gateway
	Protocol (BGP) Prefix Independent Convergence (PIC)	Protocol (BGP) Prefix-Independent Convergence (PIC) [BGP-PIC].
	[I-D.ietf-rtgwg-bgp-pic].

	Similarly, when a router needs to be taken out of service for	Similarly, when a router needs to be taken out of service for
	maintenance, the traffic is drained from the node before taking it	maintenance, the traffic is drained from the node before taking it
	down. This is typically achieved by setting the OVERLOAD bit	down. This is typically achieved by setting the OVERLOAD bit
	together with using a high metric for all prefixes advertised by the	together with using a high metric for all prefixes advertised by the
	node in IS-IS. In OSPFv2 using the cost of MaxLinkMetric for all	node in IS-IS. In OSPFv2 using the cost of MaxLinkMetric for all
	non-stub links in the router-LSA [RFC6987], or H-bit [RFC8770], and	non-stub links in the router-LSA [RFC6987], or H-bit [RFC8770], and
	R-bit for OSPFv3 [RFC5340] are mechanisms available for that purpose.	R-bit for OSPFv3 [RFC5340] are mechanisms available for that purpose.


	When prefixes from such node are summarized by an Area Border Router	When prefixes from such nodes are summarized by an Area Border Router
	(ABR) or Autonomous System Boundary Router (ASBR), nodes outside of	(ABR) or Autonomous System Boundary Router (ASBR), nodes outside of
	the area or domain are unaware of these summarized prefixes becoming	the area or domain are unaware of these summarized prefixes becoming
	unreachable. This document proposes protocol extensions to carry	unreachable. This document proposes protocol extensions to carry

	information about such prefixes in a backward compatible manner.	information about such prefixes in a backward-compatible manner.

	This document does not define how to advertise a prefix that is not	This document does not define how to advertise a prefix that is not
	reachable for routing. That has been defined for IS-IS in [RFC5305]	reachable for routing. That has been defined for IS-IS in [RFC5305]
	and [RFC5308], for OSPFv2 in [RFC2328], and for OSPFv3 in [RFC5340].	and [RFC5308], for OSPFv2 in [RFC2328], and for OSPFv3 in [RFC5340].

	This document defines a method to signal a specific reason for which	This document defines a method to signal a specific reason for which
	the prefix was advertised with the metric that excludes it from the	the prefix was advertised with the metric that excludes it from the
	route calculation. This is done to distinguish it from any other	route calculation. This is done to distinguish it from any other
	possible cases, where such metric advertisement may be used.	possible cases, where such metric advertisement may be used.


	IGP protocols typically only advertise the reachability of the	IGPs typically only advertise the reachability of the prefix. A
	prefix. Prefix that was previously advertised as reachable is made	prefix that was previously advertised as reachable is made
	unreachable just by withdrawing the previous advertisement of the	unreachable just by withdrawing the previous advertisement of the
	prefix. Some of the use cases mentioned earlier in this section	prefix. Some of the use cases mentioned earlier in this section

	require to signal unreachability for a prefix for which the	require that unreachability be signaled for a prefix for which the
	reachability was not explicitly signaled previously, because it was	reachability was not explicitly signaled previously, because it was
	covered by the reachability of the summary prefix.	covered by the reachability of the summary prefix.

	This document defines two new flags in IS-IS, OSPFv2, and OSPFv3.	This document defines two new flags in IS-IS, OSPFv2, and OSPFv3.
	These flags provide the support for advertising prefix	These flags provide the support for advertising prefix
	unreachability, together with the reason for which the unreachability	unreachability, together with the reason for which the unreachability
	is advertised. The functionality being described is called	is advertised. The functionality being described is called
	Unreachable Prefix Announcement (UPA).	Unreachable Prefix Announcement (UPA).

	This document also defines how the UPA is propagated across IS-IS	This document also defines how the UPA is propagated across IS-IS
	levels and OSPF areas.	levels and OSPF areas.


	The term OSPF in this document is used to cover both OSPFv2 and	The term "OSPF" in this document is used to cover both OSPFv2 and
	OSPFv3 protocols.	OSPFv3 protocols.


		1.1. Requirements Language

		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
		"OPTIONAL" in this document are to be interpreted as described in
		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
		capitals, as shown here.

	2. Generation of the UPA	2. Generation of the UPA

	UPA MAY be generated by an ABR or ASBR for a prefix that is	UPA MAY be generated by an ABR or ASBR for a prefix that is
	summarized by the summary prefix originated by an ABR or ASBR in the	summarized by the summary prefix originated by an ABR or ASBR in the
	following cases:	following cases:

	1. Reachability of a prefix that was reachable earlier was lost.	1. Reachability of a prefix that was reachable earlier was lost.

	2. For any of the planned maintenance cases:	2. For any of the planned maintenance cases:


	- if the node originating the prefix is signalling the	* if the node originating the prefix is signaling the overload
	overload state in IS-IS, or or H-bit in OSPFv2 [RFC8770], or	state in IS-IS, or H-bit in OSPFv2 [RFC8770], or R-bit in
	R-bit in OSPFv3 [RFC5340] .	OSPFv3 [RFC5340].


	- the metric to reach the prefix from an ABR or ASBR crosses	* the metric to reach the prefix from an ABR or ASBR crosses the
	the configured threshold.	configured threshold.

	Generation as well as propagation of the UPA at an ABR or ASBR is	Generation as well as propagation of the UPA at an ABR or ASBR is
	optional and SHOULD be controlled by a configuration knob. It SHOULD	optional and SHOULD be controlled by a configuration knob. It SHOULD
	be disabled by default.	be disabled by default.

	Implementations MAY limit the UPA generation as well as propagation	Implementations MAY limit the UPA generation as well as propagation

	to specific prefixes, e.g. host prefixes, SRv6 locators, or similar.	to specific prefixes, e.g. host prefixes, Segment Routing over IPv6
	Such filtering is optional and SHOULD be controlled via	(SRv6) locators, or similar. Such filtering is optional and SHOULD
	configuration.	be controlled via configuration.


	The intent of UPA is to provide an event driven signal of the	The intent of UPA is to provide an event-driven signal of the
	transition of a destination from reachable to unreachable. It is not	transition of a destination from reachable to unreachable. It is not
	intended to advertise a persistent state.	intended to advertise a persistent state.

	ABR or ASBR MUST withdraw the previously advertised UPA when the	ABR or ASBR MUST withdraw the previously advertised UPA when the

	reason for which the UPA was generated ceases - e.g. prefix	reason for which the UPA was generated ceases, e.g., prefix
	reachability was restored or its metric has changed such that it is	reachability was restored or its metric has changed such that it is
	below a configured threshold value.	below a configured threshold value.

	Even if the reasons persist, UPA advertisements SHOULD be withdrawn	Even if the reasons persist, UPA advertisements SHOULD be withdrawn
	after some amount of time, that would provide sufficient time for UPA	after some amount of time, that would provide sufficient time for UPA
	to be flooded network-wide and acted upon by receiving nodes, but	to be flooded network-wide and acted upon by receiving nodes, but
	limits the presence of UPA in the network. The time the UPA is kept	limits the presence of UPA in the network. The time the UPA is kept

	in the network SHOULD also reflect the intended use-case for which	in the network SHOULD also reflect the intended use case for which
	the UPA was advertised. Not withdrawing the UPA would result in	the UPA was advertised. Not withdrawing the UPA would result in
	stale information being kept in the link state database of all	stale information being kept in the link state database of all
	routers in the area.	routers in the area.

	Implementations SHOULD provide a configuration option to specify the	Implementations SHOULD provide a configuration option to specify the
	UPA lifetime at the originating ABR or ASBR.	UPA lifetime at the originating ABR or ASBR.

	As UPA advertisements in IS-IS are advertised in existing Link State	As UPA advertisements in IS-IS are advertised in existing Link State
	PDUs (LSPs) and the unit of flooding in IS-IS is an LSP, it is	PDUs (LSPs) and the unit of flooding in IS-IS is an LSP, it is
	RECOMMENDED that, when possible, UPAs are advertised in LSPs	RECOMMENDED that, when possible, UPAs are advertised in LSPs
	dedicated to this type of advertisement. This will minimize the	dedicated to this type of advertisement. This will minimize the

	number of LSPs which need to be updated when UPAs are advertised and	number of LSPs that need to be updated when UPAs are advertised and
	withdrawn.	withdrawn.

	In OSPFv2 and OSPFv3, each inter-area and external prefix is	In OSPFv2 and OSPFv3, each inter-area and external prefix is
	advertised in its own LSA, so the above consideration does not apply	advertised in its own LSA, so the above consideration does not apply
	to OSPFv2 and OSPFv3.	to OSPFv2 and OSPFv3.

	It is also RECOMMENDED that implementations limit the number of UPA	It is also RECOMMENDED that implementations limit the number of UPA

	advertisements which can be originated at a given time to limit the	advertisements that can be originated at a given time to limit the
	number of UPAs present in the network at any given point of time.	number of UPAs present in the network at any given point of time.
	UPA implementations SHOULD provide a configuration option to limit	UPA implementations SHOULD provide a configuration option to limit
	the number of such UPAs.	the number of such UPAs.

	3. Supporting UPA in IS-IS	3. Supporting UPA in IS-IS

	[RFC5305] defines the encoding for advertising IPv4 prefixes using 4	[RFC5305] defines the encoding for advertising IPv4 prefixes using 4

	octets of metric information and its section 4 specifies:	octets of metric information, and Section 4 of [RFC5305] specifies:


	"If a prefix is advertised with a metric larger than MAX_PATH_METRIC	\| If a prefix is advertised with a metric larger than
	(0xFE000000, see paragraph 3.0), this prefix MUST NOT be considered	\| MAX_PATH_METRIC (0xFE000000, see paragraph 3.0), this prefix MUST
	during the normal SPF computation. This allows advertisement of a	\| NOT be considered during the normal SPF computation. This allows
	prefix for purposes other than building the normal IP routing table."	\| advertisement of a prefix for purposes other than building the
		\| normal IP routing table.

	Similarly, [RFC5308] defines the encoding for advertising IPv6	Similarly, [RFC5308] defines the encoding for advertising IPv6

	prefixes using 4 octets of metric information and its section 2	prefixes using 4 octets of metric information and Section 2 of
	states:	[RFC5308] states:


	"...if a prefix is advertised with a metric larger than	\| ...if a prefix is advertised with a metric larger than
	MAX_V6_PATH_METRIC (0xFE000000), this prefix MUST NOT be considered	\| MAX_V6_PATH_METRIC (0xFE000000), this prefix MUST NOT be
	during the normal Shortest Path First (SPF) computation. This will	\| considered during the normal Shortest Path First (SPF)
	allow advertisement of a prefix for purposes other than building the	\| computation. This will allow advertisement of a prefix for
	normal IPv6 routing table."	\| purposes other than building the normal IPv6 routing table.

	This functionality can be used to advertise a prefix (IPv4 or IPv6)	This functionality can be used to advertise a prefix (IPv4 or IPv6)

	in a manner which indicates that reachability has been lost - and to	in a manner that indicates that reachability has been lost -- and to
	do so without requiring all nodes in the network to be upgraded to	do so without requiring all nodes in the network to be upgraded to
	support the functionality.	support the functionality.

	3.1. Advertisement of UPA in IS-IS	3.1. Advertisement of UPA in IS-IS


	Existing nodes in a network that do not suport UPA will not use UPAs	Existing nodes in a network that do not support UPA will not use UPAs
	during the route calculation, but will continue to flood them within	during the route calculation but will continue to flood them within
	the area. This allows flooding of such advertisements to occur	the area. This allows flooding of such advertisements to occur
	without the need to upgrade all nodes in a network to support this	without the need to upgrade all nodes in a network to support this
	specification.	specification.


	Those ABRs or ASBRs which are responsible for propagating UPA	Those ABRs or ASBRs that are responsible for propagating UPA
	advertisements into other areas or domains, are also expected to	advertisements into other areas or domains are also expected to
	recognise UPA advertisements.	recognize UPA advertisements.

	As per the definitions referenced in the preceding section, any	As per the definitions referenced in the preceding section, any
	prefix advertisement with a metric value greater than 0xFE000000 can	prefix advertisement with a metric value greater than 0xFE000000 can

	be used for purposes other than normal routing calculations. Such	be used for purposes other than normal routing calculations. Such a
	metric MUST be used when advertising UPA in IS-IS.	metric MUST be used when advertising UPA in IS-IS.


	[RFC7370] introduced the IS-IS Sub-TLVs for TLVs Advertising Prefix	[RFC7370] introduced the "IS-IS Sub-TLVs for TLVs Advertising Prefix
	Reachability registry which lists TLVs for advertising different	Reachability" registry, which lists TLVs for advertising different
	types of prefix reachability (that list at the time of publication of	types of prefix reachability. (The list at the time of publication
	this document is below). UPA in IS-IS is supported for prefixes	of this document is below.) UPA in IS-IS is supported for prefixes
	advertised in all such TLVs identified by that registry, e.g.:	advertised in all such TLVs identified by that registry, for example:


	- SRv6 Locator [RFC9352]	* SRv6 Locator [RFC9352]


	- Extended IP reachability [RFC5305]	* Extended IP reachability [RFC5305]


	- MT IP Reach [RFC5120]	* Multi-Topology (MT) IP Reach [RFC5120]


	- IPv6 IP Reach [RFC5308]	* IPv6 IP Reach [RFC5308]


	- MT IPv6 IP Reach [RFC5120]	* MT IPv6 IP Reach [RFC5120]


	- IPv4 Algorithm Prefix Reachability TLV [RFC9502]	* IPv4 Algorithm Prefix Reachability TLV [RFC9502]


	- IPv6 Algorithm Prefix Reachability TLV [RFC9502]	* IPv6 Algorithm Prefix Reachability TLV [RFC9502]

	3.2. Signaling UPA in IS-IS	3.2. Signaling UPA in IS-IS


	In IS-IS a prefix can be advertised with metric higher than	In IS-IS, a prefix can be advertised with a metric higher than
	0xFE000000, for various reasons. Even though in all cases the	0xFE000000, for various reasons. Even though in all cases the
	treatment of such metric is specified for IS-IS, having an explicit	treatment of such metric is specified for IS-IS, having an explicit
	way to signal that the prefix was advertised in order to signal UPA	way to signal that the prefix was advertised in order to signal UPA
	is required to distinguish it from other cases where the prefix with	is required to distinguish it from other cases where the prefix with

	such metric is advertised.	such a metric is advertised.

	Two new bits in the IPv4/IPv6 Extended Reachability Attribute Flags	Two new bits in the IPv4/IPv6 Extended Reachability Attribute Flags
	[RFC7794] are defined:	[RFC7794] are defined:


	U-Flag: - Unreachable Prefix Flag (Bit 5). When set, it indicates	U-Flag: Unreachable Prefix Flag (bit 5). When set, it indicates
	that the prefix is unreachable.	that the prefix is unreachable.


	UP-Flag: - Unreachable Planned Prefix Flag (Bit 6). When set,	UP-Flag: Unreachable Planned Prefix Flag (bit 6). When set, this
	this flag indicates that the prefix is unreachable due to a	flag indicates that the prefix is unreachable due to a planned
	planned event (e.g., planned maintenance).	event (e.g., planned maintenance).


	Originating node MUST NOT set the UP-flag without setting the	The originating node MUST NOT set the UP-flag without setting the
	U-fag.	U-flag.


	Receiving node MUST ignore the UP-flag in the advertisement if the	The receiving node MUST ignore the UP-flag in the advertisement if
	U-flag is not set.	the U-flag is not set.


	The prefix that is advertised with U-Flag MUST have the metric set to	The prefix that is advertised with the U-flag MUST have the metric
	a value larger than 0xFE000000. If the prefix metric is less than or	set to a value larger than 0xFE000000. If the prefix metric is less
	equal 0xFE000000, both of these flags MUST be ignored.	than or equal 0xFE000000, both of these flags MUST be ignored.

	3.3. Propagation of UPA in IS-IS	3.3. Propagation of UPA in IS-IS

	IS-IS L1/L2 routers, which would be responsible for propagating UPA	IS-IS L1/L2 routers, which would be responsible for propagating UPA

	advertisements between levels need to recognize such advertisements.	advertisements between levels, need to recognize such advertisements.
	Failure to do so would prevent UPA to reach the routers in the remote	Failure to do so would prevent UPA from reaching the routers in the
	areas.	remote areas.

	IS-IS allows propagation of IP prefixes in both directions between	IS-IS allows propagation of IP prefixes in both directions between
	level 1 and level 2. Propagation is only done if the prefix is	level 1 and level 2. Propagation is only done if the prefix is

	reachable in the source level, i.e., prefix is only propagated from a	reachable in the source level, i.e., the prefix is only propagated
	level in which the prefix is reachable. Such requirement of	from a level in which the prefix is reachable. Such requirement of
	reachability MUST NOT be applied for UPAs, as they are propagating	reachability MUST NOT be applied for UPAs, as they are propagating
	unreachability.	unreachability.

	IS-IS L1/L2 routers may wish to advertise received UPAs into other	IS-IS L1/L2 routers may wish to advertise received UPAs into other

	areas (upwards and/or downwards). When propagating UPAs the original	areas (upwards and/or downwards). When propagating UPAs, the
	metric value MUST be preserved. The cost to reach the originator of	original metric value MUST be preserved. The cost to reach the
	the received UPA MUST NOT be considered when readvertising the UPA.	originator of the received UPA MUST NOT be considered when
		readvertising the UPA.

	4. Supporting UPA in OSPF	4. Supporting UPA in OSPF


	[RFC2328] Appendix B defines the following architectural constant for	Appendix B of [RFC2328] defines the following architectural constant
	OSPFv2:	for OSPFv2:


	"LSInfinity The metric value indicating that the destination	\| LSInfinity
	described by an LSA is unreachable. Used in summary-LSAs and AS-	\| The metric value indicating that the destination described by
	external-LSAs as an alternative to premature aging (see	\| an LSA is unreachable. Used in summary-LSAs and AS-external-
	Section 14.1). It is defined to be the 24-bit binary value of all	\| LSAs as an alternative to premature aging (see Section 14.1).
	ones: 0xffffff."	\| It is defined to be the 24-bit binary value of all ones:
		\| 0xffffff.


	[RFC5340] Appendix B states:	Appendix B of [RFC5340] states:


	"Architectural constants for the OSPF protocol are defined in	\| Architectural constants for the OSPF protocol are defined in
	Appendix B of [OSPFV2]."	\| Appendix B of [OSPFV2].

	indicating that these same constants are applicable to OSPFv3.	indicating that these same constants are applicable to OSPFv3.


	[RFC2328] section 14.1. also describes the usage of LSInfinity as a	[RFC2328], Section 14.1 also describes the usage of LSInfinity as a
	way to indicate loss of prefix reachability:	way to indicate loss of prefix reachability:


	"Premature aging can also be used when, for example, one of the	\| Premature aging can also be used when, for example, one of the
	router's previously advertised external routes is no longer	\| router's previously advertised external routes is no longer
	reachable. In this circumstance, the router can flush its AS-	\| reachable. In this circumstance, the router can flush its AS-
	external-LSA from the routing domain via premature aging. This	\| external-LSA from the routing domain via premature aging. This
	procedure is preferable to the alternative, which is to originate a	\| procedure is preferable to the alternative, which is to originate
	new LSA for the destination specifying a metric of LSInfinity."	\| a new LSA for the destination specifying a metric of LSInfinity.
	In addition, NU-bit is defined for OSPFv3 [RFC5340]. Prefixes having
	the NU-bit set in their PrefixOptions field are not included in the	In addition, the NU-bit is defined for OSPFv3 [RFC5340]. Prefixes
	routing calculation.	having the NU-bit set in their PrefixOptions field are not included
		in the routing calculation.

	UPA in OSPFv2 is supported for prefix reachability advertised via	UPA in OSPFv2 is supported for prefix reachability advertised via

	OSPFv2 Summary-LSA [RFC2328], AS-external-LSAs [RFC2328], NSSA AS-	OSPFv2 Summary-LSA [RFC2328], AS-external-LSAs [RFC2328], Not-So-
	external LSA [RFC3101], and OSPFv2 IP Algorithm Prefix Reachability	Stubby Area (NSSA) AS-external-LSA [RFC3101], and OSPFv2 IP Algorithm
	Sub-TLV [RFC9502].	Prefix Reachability Sub-TLV [RFC9502].

	UPA in OSPFv3 is supported for prefix reachability advertised via	UPA in OSPFv3 is supported for prefix reachability advertised via
	OSPFv3 E-Inter-Area-Prefix-LSA [RFC8362], E-AS-External-LSA	OSPFv3 E-Inter-Area-Prefix-LSA [RFC8362], E-AS-External-LSA
	[RFC8362], E-Type-7-LSA [RFC8362], and SRv6 Locator LSA [RFC9513].	[RFC8362], E-Type-7-LSA [RFC8362], and SRv6 Locator LSA [RFC9513].

	For prefix reachability advertised via Inter-Area-Prefix-LSA	For prefix reachability advertised via Inter-Area-Prefix-LSA
	[RFC5340], AS-External-LSA [RFC5340], NSSA-LSA [RFC5340], UPA is	[RFC5340], AS-External-LSA [RFC5340], NSSA-LSA [RFC5340], UPA is
	signaled using their corresponding extended LSAs. This requires	signaled using their corresponding extended LSAs. This requires
	support of the OSPFv3 Extended LSAs in a sparse mode as specified in	support of the OSPFv3 Extended LSAs in a sparse mode as specified in

	section 6.2 of [RFC8362].	Section 6.2 of [RFC8362].

	4.1. Advertisement of UPA in OSPF	4.1. Advertisement of UPA in OSPF

	If an ABR or ASBR advertises UPA in an advertisement of an inter-area	If an ABR or ASBR advertises UPA in an advertisement of an inter-area

	or external prefix inside OSPFv2 or OSPFv3 then it MUST set the age	or external prefix inside OSPFv2 or OSPFv3, then it MUST set the age
	to a value lower than MaxAge and set the metric to LSInfinity.	to a value lower than MaxAge and set the metric to LSInfinity.

	UPA flooding inside the area follows the existing standard procedures	UPA flooding inside the area follows the existing standard procedures
	defined by OSPFv2 [RFC2328] and OSPFv3 [RFC5340].	defined by OSPFv2 [RFC2328] and OSPFv3 [RFC5340].

	4.2. Signaling UPA in OSPF	4.2. Signaling UPA in OSPF

	In OSPFv2 a prefix can be advertised with metric LSInfinity, or in	In OSPFv2 a prefix can be advertised with metric LSInfinity, or in

	OSPFv3 with NU-bit set in PrefixOptions, for various reasons. Even	OSPFv3 with the NU-bit set in PrefixOptions, for various reasons.
	though in all cases the treatment of such metric, or NU-bit, is	Even though in all cases the treatment of such a metric, or NU-bit,
	specified for OSPFv2 and OSPFv3, having an explicit way to signal	is specified for OSPFv2 and OSPFv3, having an explicit way to signal
	that the prefix was advertised in order to signal UPA is required to	that the prefix was advertised in order to signal UPA is required to

	distinguish it from other cases where the prefix with such metric is	distinguish it from other cases where the prefix with such a metric
	advertised.	is advertised.

	OSPFv2 and OSPFv3 Prefix Extended Flags Sub-TLVs been defined in	OSPFv2 and OSPFv3 Prefix Extended Flags Sub-TLVs been defined in
	[RFC9792] for advertising additional prefix attribute flags in OSPFv2	[RFC9792] for advertising additional prefix attribute flags in OSPFv2
	and OSPFv3.	and OSPFv3.


	Two new bits in Prefix Attributes Sub-TLV are defined:	Two new bits in the Prefix Attribute Flags Sub-TLV are defined:


	U-Flag: - Unreachable Prefix Flag (Bit 0). When set, it indicates	U-Flag: Unreachable Prefix Flag (bit 0). When set, it indicates
	that the prefix is unreachable.	that the prefix is unreachable.


	UP-Flag: - Unreachable Planned Prefix Flag (Bit 1). When set,	UP-Flag: Unreachable Planned Prefix Flag (bit 1). When set, this
	this flag indicates that the prefix is unreachable due to a	flag indicates that the prefix is unreachable due to a planned
	planned event (e.g., planned maintenance).	event (e.g., planned maintenance).


	Originating node MUST NOT set the UP-flag without setting the	The originating node MUST NOT set the UP-flag without setting the
	U-fag.	U-flag.


	Receiving node MUST ignore the UP-flag in the advertisement if the	The receiving node MUST ignore the UP-flag in the advertisement if
	U-flag is not set.	the U-flag is not set.

	4.2.1. Signaling UPA in OSPFv2	4.2.1. Signaling UPA in OSPFv2


	OSPFv2 Prefix Extended Flags Sub-TLV [RFC9792] is a Sub-TLV of the	The OSPFv2 Prefix Extended Flags Sub-TLV [RFC9792] is a sub-TLV of
	OSPFv2 Extended Prefix TLV [RFC7684].	the OSPFv2 Extended Prefix TLV [RFC7684].

	The prefix that is advertised with U-Flag MUST have the metric set to	The prefix that is advertised with U-Flag MUST have the metric set to
	a value LSInfinity. If the prefix metric is not equal to LSInfinity,	a value LSInfinity. If the prefix metric is not equal to LSInfinity,
	both of these flags MUST be ignored. For default algorithm 0	both of these flags MUST be ignored. For default algorithm 0
	prefixes with U-Flag it is therefore REQUIRED to advertise the	prefixes with U-Flag it is therefore REQUIRED to advertise the
	unreachable prefix in the base OSPFv2 LSA - e.g., OSPFv2 Summary-LSA	unreachable prefix in the base OSPFv2 LSA - e.g., OSPFv2 Summary-LSA
	[RFC2328], or AS-external-LSAs [RFC2328], or NSSA AS-external LSA	[RFC2328], or AS-external-LSAs [RFC2328], or NSSA AS-external LSA
	[RFC3101].	[RFC3101].

	4.2.2. Signaling UPA in OSPFv3	4.2.2. Signaling UPA in OSPFv3


	OSPFv3 Prefix Extended Flags Sub-TLV is defined as a Sub-TLV of the	OSPFv3 Prefix Extended Flags Sub-TLV is defined as a sub-TLV of the
	following OSPFv3 TLVs that are defined in [RFC8362]:	following OSPFv3 TLVs that are defined in [RFC8362]:


	Intra-Area Prefix TLV	* Intra-Area Prefix TLV


	Inter-Area Prefix TLV	* Inter-Area Prefix TLV


	External Prefix TLV	* External Prefix TLV

	The prefix that is advertised with U-Flag or UP-flag MUST have the	The prefix that is advertised with U-Flag or UP-flag MUST have the
	metric set to a value LSInfinity. For default algorithm 0 prefixes,	metric set to a value LSInfinity. For default algorithm 0 prefixes,
	the LSInfinity MUST be set in the parent TLV. For IP Algorithm	the LSInfinity MUST be set in the parent TLV. For IP Algorithm
	Prefixes [RFC9502], the LSInfinity MUST be set in OSPFv3 IP Algorithm	Prefixes [RFC9502], the LSInfinity MUST be set in OSPFv3 IP Algorithm
	Prefix Reachability sub-TLV. If the prefix metric is not equal to	Prefix Reachability sub-TLV. If the prefix metric is not equal to
	LSInfinity, both of these flags MUST be ignored.	LSInfinity, both of these flags MUST be ignored.

	The prefix that is advertised with U-Flag or UP-Flag MUST have the	The prefix that is advertised with U-Flag or UP-Flag MUST have the
	NU-bit set in the PrefixOptions of the parent TLV. If the NU-bit in	NU-bit set in the PrefixOptions of the parent TLV. If the NU-bit in
	PrefixOptions of the parent TLV is not set, both of these flags MUST	PrefixOptions of the parent TLV is not set, both of these flags MUST
	be ignored.	be ignored.

	4.3. Propagation of UPA in OSPF	4.3. Propagation of UPA in OSPF

	OSPF ABRs, which would be responsible for propagating UPA	OSPF ABRs, which would be responsible for propagating UPA

	advertisements into other areas need to recognize such	advertisements into other areas, need to recognize such
	advertisements. Failure to do so would prevent UPA to reach the	advertisements. Failure to do so would prevent UPA from reaching the
	routers in the remote areas.	routers in the remote areas.

	Advertising prefix reachability between OSPF areas assumes prefix	Advertising prefix reachability between OSPF areas assumes prefix

	reachability in a source area. Such requirement of reachability MUST	reachability in a source area. Such a requirement of reachability
	NOT be applied for UPAs, as they are propagating unreachability.	MUST NOT be applied for UPAs, as they are propagating unreachability.

	OSPF ABRs or ASBRs MAY advertise received UPAs between connected	OSPF ABRs or ASBRs MAY advertise received UPAs between connected
	areas or domains. When doing so, the original LSInfinity metric	areas or domains. When doing so, the original LSInfinity metric
	value in UPA MUST be preserved. The cost to reach the originator of	value in UPA MUST be preserved. The cost to reach the originator of
	the received UPA MUST NOT be considered when readvertising the UPA to	the received UPA MUST NOT be considered when readvertising the UPA to
	connected areas.	connected areas.

	5. Processing of the UPA	5. Processing of the UPA

	Processing of the received UPAs is optional and SHOULD be controlled	Processing of the received UPAs is optional and SHOULD be controlled
	by the configuration at the receiver. The receiver itself, based on	by the configuration at the receiver. The receiver itself, based on
	its configuration, decides what the UPA will be used for and what	its configuration, decides what the UPA will be used for and what
	applications, if any, will be notified when UPA is received. Usage	applications, if any, will be notified when UPA is received. Usage
	of the UPA at the receiver is outside of the scope of this document.	of the UPA at the receiver is outside of the scope of this document.

	As an example, UPA may be used to trigger BGP PIC Edge at the	As an example, UPA may be used to trigger BGP PIC Edge at the

	receiving router [I-D.ietf-rtgwg-bgp-pic].	receiving router [BGP-PIC].

	Applications using the UPA cannot use the absence of the UPA to infer	Applications using the UPA cannot use the absence of the UPA to infer
	that the reachability of the prefix is back. They must rely on their	that the reachability of the prefix is back. They must rely on their

	own mechanisms to verify the reachability of the remote end-points.	own mechanisms to verify the reachability of the remote endpoints.

	6. Area and Domain Partition	6. Area and Domain Partition

	UPA is not meant to address an area/domain partition. When an area	UPA is not meant to address an area/domain partition. When an area
	or domain partitions, while multiple ABRs or ASBRs advertise the same	or domain partitions, while multiple ABRs or ASBRs advertise the same

	summary, each of them can only reach portion of the summarized	summary, each of them can only reach a portion of the summarized
	prefix. As a result, depending on which ABR or ASBR the traffic is	prefix. As a result, depending on which ABR or ASBR the traffic is
	using to enter a partitioned area, the traffic could be either	using to enter a partitioned area, the traffic could be either
	dropped or delivered to its final destination. UPA does not make the	dropped or delivered to its final destination. UPA does not make the

	problem of an area partition any worse. In case of an area partition	problem of an area partition any worse. In case of an area
	each of an ABRs or ASBRs will generate UPAs for the destinations for	partition, each ABR or ASBR will generate UPAs for the destinations
	which the reachability was lost locally. As the UPA propagates to	for which the reachability was lost locally. As the UPA propagates
	the nodes outside of a partitioned area, it may result in such nodes	to the nodes outside a partitioned area, it may result in such nodes
	picking an alternative egress node for the traffic, if such alternate	picking an alternative egress node for the traffic, if such a node
	egress node exists. If such alternate egress node resides outside of	exists. If such an alternative egress node resides outside a
	a partitioned area, traffic will be restored. If such alternate	partitioned area, traffic will be restored. If such an alternative
	egress node resides in a partitioned area and is covered by the	egress node resides in a partitioned area and is covered by the

	summary, the trafic will be dropped if it enters a partitioned area	summary, the traffic will be dropped if it enters a partitioned area
	via an ABR or ASBR that can not reach the alternate egress node -	via an ABR or ASBR that cannot reach that node. This will result in
	resulting in similar behavior as without the UPA. Above is similarly	similar behavior as without the UPA. The above statements are also
	applicable to a domain partition.	applicable to a domain partition.

	7. IANA Considerations	7. IANA Considerations

	7.1. IS-IS Prefix Attribute Flags Sub-TLV	7.1. IS-IS Prefix Attribute Flags Sub-TLV

	This document adds two new bits in the "IS-IS Bit Values for Prefix	This document adds two new bits in the "IS-IS Bit Values for Prefix
	Attribute Flags Sub-TLV" registry:	Attribute Flags Sub-TLV" registry:


	Bit #: 5	Bit #: 5
		Name: U-Flag
	Description: U-Flag	Reference: RFC 9929 (Section 3.2)

	Reference: This document (Section 3.2).

	Bit #: 6

	Description: UP-Flag


	Reference: This document (Section 3.2).	Bit #: 6
		Name: UP-Flag
		Reference: RFC 9929 (Section 3.2)


	7.2. OSPFv2 and OSPFv3 OSPFv2 Prefix Extended Flags	7.2. OSPFv2 and OSPFv3 Prefix Extended Flags

	This document adds two new bits in the "OSPFv2 Prefix Extended Flags"	This document adds two new bits in the "OSPFv2 Prefix Extended Flags"
	and "OSPFv3 Prefix Extended Flags" registries:	and "OSPFv3 Prefix Extended Flags" registries:


	Bit #: 0	Bit: 0
		Description: U-Flag
	Description: U-Flag	Reference: RFC 9929 (Section 4.2)

	Reference: This document (Section 4.2).

	Bit #: 1

	Description: UP-Flag


	Reference: This document (Section 4.2).	Bit: 1
		Description: UP-Flag
		Reference: RFC 9929 (Section 4.2)

	8. Security Considerations	8. Security Considerations

	The use of UPAs introduces the possibility that an attacker could	The use of UPAs introduces the possibility that an attacker could
	inject a false, but apparently valid, UPA. However, the risk of this	inject a false, but apparently valid, UPA. However, the risk of this
	occurring is no greater than the risk today of an attacker injecting	occurring is no greater than the risk today of an attacker injecting
	any other type of false advertisement.	any other type of false advertisement.

	The risks can be reduced by the use of existing security extensions	The risks can be reduced by the use of existing security extensions
	as described in:	as described in:


	- [RFC5304], [RFC5310], and [RFC7794] for IS-IS.	* [RFC5304], [RFC5310], and [RFC7794] for IS-IS.

	- [RFC2328], [RFC7474] and [RFC7684] for OSPFv2.

	- [RFC5340], [RFC4552] and [RFC8362] for OSPFv3.

	9. Acknowledgements

	The authors would like to thank Kamran Raza, Michael MacKenzie and
	Luay Jalil for their contribution and support of the overall solution
	proposed in this document.

	10. Contributors

	The following people contributed to the content of this document and
	should be considered coauthors:

	Stephane Litkowski
	Email: slitkows@cisco.com

	Amit Dhamija
	Email: amitd@arrcus.com

	Gunter Van de Velde
	Email: gunter.van_de_velde@nokia.com

	The following people contributed to the problem statement and the
	solution requirement discussion:


	Aijun Wang	* [RFC2328], [RFC7474], and [RFC7684] for OSPFv2.
	Email: wangaj3@chinatelecom.cn


	Zhibo Hu	* [RFC5340], [RFC4552], and [RFC8362] for OSPFv3.
	Email: huzhibo@huawei.com


	11. References	9. References


	11.1. Normative References	9.1. Normative References


	[ISO10589] ISO, "Intermediate system to Intermediate system intra-	[ISO10589] ISO/IEC, "Information technology -- Telecommunications and
	domain routeing information exchange protocol for use in	information exchange between systems -- Intermediate
	conjunction with the protocol for providing the	System to Intermediate System intra-domain routeing
	connectionless-mode Network Service (ISO 8473)", November	information exchange protocol for use in conjunction with
	2002.	the protocol for providing the connectionless-mode network
		service (ISO 8473)", ISO/IEC 10589:2002, November 2002,
		<https://www.iso.org/en/contents/data/
		standard/03/09/30932.html>.

	[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,	Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,	DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.	<https://www.rfc-editor.org/info/rfc2119>.

	[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,	[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
	DOI 10.17487/RFC2328, April 1998,	DOI 10.17487/RFC2328, April 1998,
	<https://www.rfc-editor.org/info/rfc2328>.	<https://www.rfc-editor.org/info/rfc2328>.


	skipping to change at page 16, line 20 ¶	skipping to change at line 679 ¶
	[RFC9513] Li, Z., Hu, Z., Talaulikar, K., Ed., and P. Psenak,	[RFC9513] Li, Z., Hu, Z., Talaulikar, K., Ed., and P. Psenak,
	"OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)",	"OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)",
	RFC 9513, DOI 10.17487/RFC9513, December 2023,	RFC 9513, DOI 10.17487/RFC9513, December 2023,
	<https://www.rfc-editor.org/info/rfc9513>.	<https://www.rfc-editor.org/info/rfc9513>.

	[RFC9792] Chen, R., Zhao, D., Psenak, P., Talaulikar, K., and L.	[RFC9792] Chen, R., Zhao, D., Psenak, P., Talaulikar, K., and L.
	Gong, "Prefix Flag Extension for OSPFv2 and OSPFv3",	Gong, "Prefix Flag Extension for OSPFv2 and OSPFv3",
	RFC 9792, DOI 10.17487/RFC9792, June 2025,	RFC 9792, DOI 10.17487/RFC9792, June 2025,
	<https://www.rfc-editor.org/info/rfc9792>.	<https://www.rfc-editor.org/info/rfc9792>.


	11.2. Informative References	9.2. Informative References


	[I-D.ietf-rtgwg-bgp-pic]	[BGP-PIC] Bashandy, A., Ed., Filsfils, C., Mohapatra, P., and Y. Qu,
	Bashandy, A., Filsfils, C., and P. Mohapatra, "BGP Prefix	"BGP Prefix Independent Convergence", Work in Progress,
	Independent Convergence", Work in Progress, Internet-	Internet-Draft, draft-ietf-rtgwg-bgp-pic-23, 15 February
	Draft, draft-ietf-rtgwg-bgp-pic-22, 20 April 2025,	2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
	<https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-	rtgwg-bgp-pic-23>.
	bgp-pic-22>.
		Acknowledgements

		The authors would like to thank Kamran Raza, Michael MacKenzie, and
		Luay Jalil for their contributions and support of the overall
		solution proposed in this document.

		Contributors

		The following people contributed to the content of this document and
		should be considered coauthors:

		Stephane Litkowski
		Email: slitkows@cisco.com

		Amit Dhamija
		Email: amitd@arrcus.com

		Gunter Van de Velde
		Email: gunter.van_de_velde@nokia.com

		The following people contributed to the problem statement and the
		solution requirement discussion:

		Aijun Wang
		Email: wangaj3@chinatelecom.cn

		Zhibo Hu
		Email: huzhibo@huawei.com

	Authors' Addresses	Authors' Addresses

	Peter Psenak (editor)	Peter Psenak (editor)
	Cisco Systems	Cisco Systems
	Pribinova Street 10	Pribinova Street 10
	Bratislava 81109	Bratislava 81109
	Slovakia	Slovakia
	Email: ppsenak@cisco.com	Email: ppsenak@cisco.com


End of changes. 97 change blocks.
	275 lines changed or deleted	270 lines changed or added
This html diff was produced by rfcdiff 1.48.