2. Generation of the UPA

Cette section conserve le texte RFC pour Unreachable Prefix Announcement (UPA), y compris IS-IS and OSPF signaling, U-Flag and UP-Flag semantics, propagation rules, IANA assignments et security considerations.

2.  Generation of the UPA

   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
   following cases:

   1.  A prefix that was reachable earlier becomes unreachable.

   2.  For any of the planned maintenance cases:

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

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

   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
   be disabled by default.

   Implementations MAY limit the UPA generation as well as propagation
   to specific prefixes, e.g. host prefixes, Segment Routing over IPv6
   (SRv6) locators, or similar.  Such filtering is optional and SHOULD
   be controlled via configuration.

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

   ABR or ASBR MUST withdraw the previously advertised UPA when the
   reason for which the UPA was generated ceases, e.g., prefix
   reachability was restored or its metric has changed such that it is
   below a configured threshold value.

   Even if the reasons persist, UPA advertisements SHOULD be withdrawn
   after some amount of time, that would provide sufficient time for UPA
   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
   in the network SHOULD also reflect the intended use case for which
   the UPA was advertised.  Not withdrawing the UPA would result in
   stale information being kept in the link state databases of all
   routers in the area.

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

   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
   RECOMMENDED that, when possible, UPAs are advertised in LSPs
   dedicated to this type of advertisement.  This will minimize the
   number of LSPs that need to be updated when UPAs are advertised and
   withdrawn.

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

   It is also RECOMMENDED that implementations limit the number of UPA
   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.
   UPA implementations SHOULD provide a configuration option to limit
   the number of such UPAs.