IGP Unreachable Prefix Announcement
draft-ietf-lsr-igp-ureach-prefix-announce-11

[Ballot comment]
Are there any operational considerations worth mentioning in the document? Would setting the UP flag cause other properly implemented systems not supporting the flag to change behaviour? I assume this would not be the case and that is why no operational considerations were added?

[Ballot comment]
Section 1:
- Expand terms on first use; at least IGP and possibly OSPF, IS-IS, BGP, PIC, etc.
- "multi-area/level and/or multi-domain" Is there a reason to split area/level from domain?
- "Summarization" appears to be a key concept here. Can you add a pointer to a definition?

It's unfortunate that the abbreviation "UP" is being used to indicate that something is down.

===NITS FOLLOW===

Abstract: "the two new flags" haven't been described yet. Maybe drop "the"

1: "OVERLOAD bit" => "the OVERLOAD bit", "high metric" => "a high metric", "all-links" => "all links", "such load" => "such a load", "advertise prefix" => "advertise a prefix"

4.2: Remove comma after "ASBRs"

[Ballot comment]
Hi Peter, all,

Thank you for the discussion and addressing raised points in [1]. -10 looks much more better.

I still think that we can git rid of the UP-flag and leave it to when we have more clarity on the intended application use, though.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/lsr/ZBY0n8RSx0NAOuG_00E6dW6OgEg/

[Ballot comment]
Thanks to the authors and the WG for their work on this document.

I believe this is a useful feature in specific deployment use cases where
summarization is used for scaling purposes.

Thanks to Peter for addressing my comments in the DISCUSS and COMMENTS sections as the editor of the document.

[Ballot comment]
Section 1, paragraph 0
>    Link-state IGP protocols like IS-IS [ISO10589], OSPF [RFC2328], and
>    OSPFv3 [RFC5340] are primarily used to distribute routing information
>    between routers belonging to a single Autonomous System (AS) and to
>    calculate the reachability for IPv4 or IPv6 prefixes advertised by
>    the individual nodes inside the AS.  Each node advertises the state
>    of its local adjacencies, connected prefixes, capabilities, etc.  The
>    collection of these states from all the routers inside the area form
>    a link-state database (LSDB) that describes the topology of the area
>    and holds additional state information about the prefixes, router
>    capabilities, etc.

Use of OSPF, OSPFv2 and OSPFv3 is confusing in this draft. The title of RFC2328 is "OSPF Version 2", not "OSPF", which is often used to refer to both OSPFv2 and OSPFv3. Could the authors correct and clarify when the statement is applicable to OSPFv2, or OSPFv3 or both (by using OSPF).

Section 2, paragraph 9
>    It is also RECOMMENDED that implementations limit the number of UPA
>    advertisements which can be originated at a given time.

This and other Sections documents several configuration parameters, including a knob to enable the advertisment of UPA and the reception and processing of them. It would be useful to summarize all the configuration (and maintenance) options this document is introducing in a separate section called "Operational Considerations".

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term "traditionally"; alternatives might be "classic", "classical",
  "common", "conventional", "customary", "fixed", "habitual", "historic",
  "long-established", "popular", "prescribed", "regular", "rooted",
  "time-honored", "universal", "widely used", "widespread"

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1, paragraph 3
>    IGP protocols typically only advertise the reachability of the
>    prefix.  Prefix that was previously advertised as reachable is made
>    unreachable just by withdrawing the previous advertisement of the
>    prefix.  In our use case, we want to signal unreachability for a
>    prefix for which the reachability was not explicitly signaled
>    previously, because it was covered by the reachability of the summary
>    address.

As Eric has already commented, who is "ours" or "we"? Please avoid the usage of such terms.

Section 1, paragraph 3
>    This document also defines how the UPA is propagated across ISIS
>    levels and OSPF areas.

s/ISIS/IS-IS/ here and everywhere in the document.

Section 2, paragraph 6
>    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.  UPA advertisements SHOULD
>    therefore be withdrawn after some amount of time, that would provides
>    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.

s/that would provides/that would provide/

Document references draft-ietf-lsr-ospf-prefix-extended-flags, but that has
been published as RFC9792.

Section 2, paragraph 5
> e UPA was advertised. s/that would provides/that would provide/ Implementatio
>                                    ^^^^^^^^
The modal verb "would" requires the verb's base form.

Section 2, paragraph 6
> nd external prefix is advertised in it's own LSA, so the above optimisation
>                                    ^^^^
Did you mean "its" (possessive pronoun) instead of "it's" (short for "it is")?

Section 2, paragraph 9
> efix is advertised with a metric larger then MAX_PATH_METRIC (0xFE000000, see
>                                  ^^^^^^^^^^^
Did you mean "larger than"?

Section 3, paragraph 6
> s initially defined in [RFC7370], e.g.,: - SRv6 Locator [RFC9352] - Extended
>                                      ^^
Did you just mean "," or ":"?

[Ballot discuss]
Hi Peter, Clarence, Daniel, Shraddha, and Gyan,

Thank you for the effort put into this specification.

I like the approach adopted here as it leverages exiting features (which is good for backward compatibility) and thus eases incremental deployment.

# Meta comment

The flow of the document can be made better by introducing the explicit signaling part early in the document as that is what actually demux the use defined in the draft vs. any other future uses of the specific metric. The current flow reveals that the signaling part was added as an after though, not as part of the design.

Please find below some DICUSS points:

# Planned Maintenance

I expect that adequate reconfiguration will be put in place to isolate a node for PM purposes. The document does not explain how the signal defined here is needed or solves an issue. I appreciate that the introduction includes a short mention of the use of overload bit, though.

I’m also asking the question because there is no ** normative ** discussion (at least I missed it) about how that can be triggered at the originating ABR.

Also, unlike a random failure, a planned failure is associated with an expected start and end times. Signaling the event without those characteristics questions the value of tagging a loss as an UP (over-specification). 

# Configuration Efficiency

Section 2
  Implementations MAY limit the UPA generation to specific prefixes,
  e.g.  host prefixes, SRv6 locators, or similar.  Such filtering is
  optional and MAY be controlled via configuration.

I’m afraid that for the limit to be useful, it should be tweaked based on local operator policy, not on some magic that is internal to the implementation. I suggest the second MAY to be changed to SHOULD when such limit is supported.

Idem for the following:
  Implementation MAY provide a configuration option to specify the UPA
  lifetime at the originating ABR or ASBR.

I suggest we update it to:

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

The reasoning for this change is that a failure may last long and that an operator would like to maintain that loss state longer (than allowed by a default limit) to accommodate how the specific application consuming the loss signal.

Please note that you say that the validity depends on the use case:

CURRENT (S.2):
  The
  time the UPA is kept in the network SHOULD also reflect the intended
  use-case for which the UPA was advertised.

# Withdrawal

Section 2 says:

  UPA advertisements SHOULD
  therefore be withdrawn after some amount of time, that would provides
  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.
  …
  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 the configured threshold value.

The second MUST is not useful if that reason disappears after the timeout that triggers the SHOULD.

I think a simple text reorder would fix this. For example,

NEW:
  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 the configured threshold value.

  Even if the reasons persist, UPA advertisements SHOULD
  be withdrawn after some amount of time, that would provides
  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.

# Scalability control

Section 2 says:
  It is also RECOMMENDED that implementations limit the number of UPA
  advertisements which can be originated at a given time.

The benefits gained by summarization may be nullified if a large number of UPAs are injected. This recommendation is really great, but there is a need to expose a configuration parameter here. Consider add the following:

NEW:
  UPA implementations SHOULD provide a configuration option to limit
  the number of such UPAs.

# Backward compatibility Check

CURRENT (3.2/4.2):
  Such requirement of
  reachability MUST NOT be applied for UPAs, as they are propagating
  unreachability.

Does this mean that an ABR that don’t support UPA might discard it?

# Avoid redefining exiting behaviors

CURRENT (Section 4):
  In addition, NU-bit is defined for OSPFv3 [RFC5340].  Prefixes having
  the NU-bit set in their PrefixOptions field SHOULD NOT be included in
  the routing calculation.

The SHOULD NOT part is already defined in 5340. Why is this redefined again?

# Check on “UP-Flag” is useless

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

5.2.2
  The prefix that is advertised with U-Flag or UP-Flag MUST have the
  NU-bit set in the PrefixOptions of the parent TLV. 

The “or UP-Flag” part of both MUSTs is useless as U-Flag will be set if UP-Flag is set as well. The case where only UP-Flag is set is invalid and will be ignored.

Unless I missed a subtle thing here, please update these two accordingly.

# Service stability

The document declares the applications that consume the signal out of scope. Which is fine. However, there might be some negative implications due to how the loss signal (or it withdrawal/absence) is interpreted. For example, add a warning to insist that withdrawal does not mean revert to a nominal state. Having few sentences for these service to take appropriate measure before reverting.

[Ballot discuss]
Hi Peter, Clarence, Daniel, Shraddha, and Gyan,

Thank you for the effort put into this specification.

I like the approach adopted here as it leverages exiting features (which is good for backward compatibility) and thus eases incremental deployment.

# Meta comment

The flow of the document can be made better by introducing the explicit signaling part early in the document as that is what actually demux the use defined in the draft vs. any other future uses of the specific metric. The current flow reveals that the signaling part was added as an after though, not as part of the design.

Please find below some DICUSS points:

# Planned Maintenance

I expect that adequate reconfiguration will be put in place to isolate a node for PM purposes. The document does not explain how the signal defined here is needed or solves an issue. I appreciate that the introduction include a short mention of the use of overload bit, though.

I’m also asking the question because there is no ** normative ** discussion (at least I missed it) about how that can be triggered at the originating ABR.

Also, unlike a random failure, a planned failure is associated with an expected start and end times. Signaling the event without those characteristic questions the value of tagging a loss as an NP. 

# Configuration Efficiency

Section 2
  Implementations MAY limit the UPA generation to specific prefixes,
  e.g.  host prefixes, SRv6 locators, or similar.  Such filtering is
  optional and MAY be controlled via configuration.

I’m afraid that for the limit to be useful, it should be tweaked based on local operator policy and not on some magic that is internal to the implementation. I suggest the second MAY to be changed to SHOULD when such limit is supported.

Idem for the following:
  Implementation MAY provide a configuration option to specify the UPA
  lifetime at the originating ABR or ASBR.

I suggest we update it to:

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

The reasoning for this change is that a failure may last long and that an operator would like to maintain that loss state longer (than allowed by a default limit) to accommodate how the specific application consuming the loss signal.

Please note that you say that the validity depends on the use case:

CURRENT (S.2):
  The
  time the UPA is kept in the network SHOULD also reflect the intended
  use-case for which the UPA was advertised.

# Withdrawal

Section 2 says:

  UPA advertisements SHOULD
  therefore be withdrawn after some amount of time, that would provides
  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.
  …
  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 the configured threshold value.

The second MUST is not useful if that reason disappears before the timeout that triggers the SHOULD.

I think a simple text reorder would fix this. For example,

NEW:
  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 the configured threshold value.

  Even if the reasons persist, UPA advertisements SHOULD
  be withdrawn after some amount of time, that would provides
  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.

# Scalability control

Section 2 says:
  It is also RECOMMENDED that implementations limit the number of UPA
  advertisements which can be originated at a given time.

The benefits gained by summarization may be nullified if a large number of UPAs are injected. This recommendation is really great, but there is a need to expose a configuration parameter here. Pease

NEW:
  UPA implementations SHOULD provide a configuration option to limit
  the number of such UPAs.

# Backward compatibility Check

CURRENT (3.2/4.2):
  Such requirement of
  reachability MUST NOT be applied for UPAs, as they are propagating
  unreachability.

Does this mean that an ABR that don’t support UPA might discard it?

# Avoid redefining exiting behaviors

CURRENT (Section 4):
  In addition, NU-bit is defined for OSPFv3 [RFC5340].  Prefixes having
  the NU-bit set in their PrefixOptions field SHOULD NOT be included in
  the routing calculation.

The SHOULD NOT part is already defined in 5340. What is this redefined again?

# Check on “UP-Flag” is useless

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

5.2.2
  The prefix that is advertised with U-Flag or UP-Flag MUST have the
  NU-bit set in the PrefixOptions of the parent TLV. 

The “or UP-Flag” part of both MUSTs is useless as U-Flag will be set in such case as well. The case where only UP-Flag is set is invalid and will be ignored.

Unless I missed a subtle thing here, please update these two.

# Service stability

The document declares the applications that consume the signal out of scope. Which is fine. However, there might be some negative implications due to how the loss signal (or it withdrawal/absence) is interpreted. For example, add a warning to insist that withdrawal does not mean revert to a nominal state. Having few sentences for these service to take appropriate measure before reverting.

[Ballot comment]
# Topology-dependent matters

Abstract:
  This enables fast
  convergence by steering traffic away from the node which owns the
  prefix and is no longer reachable.

“steering..” part of the text is only possible when there alternate routes for that prefix. Otherwise, the traffic will be dropped anyway.

Pleas reword. For example, saying “when applicable” or similar would be just fine.

# Why now?

Summarization was there since decades. A mention about what exacerbates the need for this new feature now (and was not considered as a major issue in past) would be helpful.

# "Egress" depends on the traffic directionality

Section 1:
  Similarly, when an egress router needs to be taken out of service for
  maintenance, the traffic is drained from the node before taking it
  down. 

A router may behave as ingress/egress as a function of traffic direction. I would delete “egress” here.

# (ni) There might be many ABRs per area, not single one

Please make this change in Section 1 (and similar):

OLD:
  When prefixes from such node are summarized by the
  Area Border Router (ABR) or Autonomous System Boundary Router (ASBR),

NEW:
  When prefixes from such node are summarized by an
  Area Border Router (ABR) or Autonomous System Boundary Router (ASBR),

# (Operational Considerations) Many signals, distinct expected uses

Section 1 has the following:

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

I wonder whether we can list the signals available out there (explicit prefer advertisement, prefix with a specific metric, etc.) and remind the intend use scope for each of them. This can be record in the Operational Considerations.

I’m raising this point, especially that the text right after says the following without appropriate scoping:

CURRENT:
  This document defines two new flags in IS-IS, OSPF, and OSPFv3.
  These flags, together with the existing protocol mechanisms, provide
  the support for advertising prefix unreachability , together with the
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  reason for which the unreachability is advertised

# Unreachable metric?!

Section 1 has the following:
  This document defines a method to signal a specific reason for which
  the prefix with unreachable metric was advertised. 

Unless, I’m mistaken there is no such “unreachable metric” as a thing in IS-IS.

# (Operational Considerations) Activation default

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

Can we say something about whether the use of UPA be enabled or disabled by default?

# Threshold

Section 2 says:
          - the metric to reach the prefix from the ABR or ASBR crosses
          the configured threshold.

Can we explicit the threshold we are referring to here + add reference where to look at?

# Explicit references in Section 3

OLD:
  [RFC5305] defines the encoding for advertising IPv4 prefixes using 4
  octets of metric information.  Section 4 specifies:
  ..
  Similarly, [RFC5308] defines the encoding for advertising IPv6
  prefixes using 4 octets of metric information. Section 2 states:

NEW:
  [RFC5305] defines the encoding for advertising IPv4 prefixes using 4
  octets of metric information.  Section 4 of [RFC5305]  specifies:
  ..
  Similarly, [RFC5308] defines the encoding for advertising IPv6
  prefixes using 4 octets of metric information.  Section 2 of [RFC5308] states:

# “Advertisement of UPA in IS-IS”

CURENT (S3.1)
  Recognition of the advertisement as UPA is only required on routers
  which have a valid use case for this information. 

I would delete this sentence as this section is about the originator.

# Section 6

Consider moving that section right after current Section 7 as a subsection of an Operational Consideration section.

## Multiple ABRs

That section may also discuss whether there are specific consideration to take into account, e.g., presence of multiple ABRs with announces UPAs for a set of prefixes in an area and measures to prevent routing stability. If you don’t see any risk out there, saying that as well would be useful.

## Consider adding any implications (or absence of) explicit withdrawal of an UPA.

Cheers,
Med

[Ballot comment]
# Internet AD comments for draft-ietf-lsr-igp-ureach-prefix-announce-09
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S5.1,5.2

* It seems to me that using the letters "UP" to mean "no, actually down"
  could bring no small amount of confusion.

  But I assume the working group discussed options and this was the best
  that could achieve consensus.

## Nits

### S1

* "reachability of the summary address" ->
  "reachability of the summary prefix"

[Ballot discuss]
Thanks to the authors and the WG for their work on this document.

I believe this is a useful feature in specific deployment use cases where
summarization is used for scaling purposes.

I have a few points that I would like to discuss.

discuss#1: Feature Enablement - I believe that UPA is an optional feature
of IGPs and not a core IGP functionality. Therefore, it should be disabled by
default. While there is text in the document about various control knobs and
parameters for implementations, I was not able to find anything about
enablement (at originating, propagating, and receiving routers?) which I
believe is required?

discuss#2: Limit/control at ABR/ASBR - Just like the ABR/ABSR
that are originating UPAs, is some control and limit expected at an ABR/ASBR
that is propagating UPAs? Is there some check required that those UPAs are
covered by a summary that is being also propagated (or originated) by that
ABR/ASBR?

discuss#3: section 4 says:

"UPA in OSPFv3 is supported for Inter-Area-Prefix-LSA [RFC5340], AS-External-LSA [RFC5340], NSSA-LSA [RFC5340], E-Inter-Area-Prefix-LSA [RFC8362], E-AS-External-LSA [RFC8362], E-Type-7-LSA [RFC8362], and SRv6 Locator LSA [RFC9513]."

I would like to understand why the base OSPFv3 LSAs are required for UPA and why it cannot be done with just the extended LSAs (operating in sparse mode) and the SRv6 Locator LSA. It is likely that I am missing something and hence asking for clarification.

[Ballot comment]
Please find below some comments provided in the idnits output of the v09 of
the document. Please look for  at the end of the email. If that is not
present then likely the email has been truncated by your email client.

24   This document describes how to use the existing protocol mechanisms
25   in IS-IS and OSPF, together with the two new flags, to advertise such
26   prefix reachability loss.

Perhaps remove "existing" from the above sentence in view of sections
3.2 and 4.2?


126   IS, or by setting high metric on all-links and prefixes advertised by
127   the node in OSPF.  When prefixes from such node are summarized by the

For OSPF, is the reference here to MaxLinkMetric in RFC6987 and LSInfinity?
Perhaps also the H-bit for v2 [RFC8870] and R-bit for v3 [RFC5340]?


151   This document defines two new flags in IS-IS, OSPF, and OSPFv3.
152   These flags, together with the existing protocol mechanisms, provide

Perhaps remove "existing" here as well for the same reasons as
previous comment?


160 2.  Generation of the UPA

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

Should we also call out that UPA MUST NOT be generated unless it is covered
by a summary?


204   In OSPF and OSPFv3, each inter-area and external prefix is advertised
205   in it's own LSA, so the above optimisation does not apply to OSPF.

s/optimisation/consideration ? ... or perhaps "constraint" ?

207   It is also RECOMMENDED that implementations limit the number of UPA
208   advertisements which can be originated at a given time.

Is the intention here about how many can be originated in one go OR how many
UPAs would be present (active) in that routers LSAs/LSPs at any given point of time? I
am assuming it is the latter and if so please clarify.

210 3.  Supporting UPA in IS-IS

212   [RFC5305] defines the encoding for advertising IPv4 prefixes using 4
213   octets of metric information.  Section 4 specifies:

For clarity, suggest:

[RFC5305] defines the encoding for advertising IPv4 prefixes using 4 octets of
metric information and its Section 4 specifies:


234 3.1.  Advertisement of UPA in IS-IS

236   Existing nodes in a network that do not suport UPA will not use UPAs
237   during the route calculation, but will continue to flood them.  This
238   allows flooding of such advertisements to occur without the need to
239   upgrade all nodes in a network.

Should "will continue to flood them" be qualified as "will continue to
flood them within the level" or something on similar lines?

241   Recognition of the advertisement as UPA is only required on routers
242   which have a valid use case for this information.  Those ABRs or
243   ASBRs, which are responsible for propagating UPA advertisements into
244   other areas or domains MUST also recognize UPA advertisements.

Perhaps s/domains MUST also recognize/domains are also expected to
recognize ... or word it differently since this is more like an
operational/deployment guideline for UPA feature? If providing operational or
deployment considerations, then suggest to introduce a new section named as such
and describe which routers are expected to be UPA-aware (or this could be done in
section 2 with a title change that covers not just generation but other aspects
as well).


251   UPA in IS-IS is supported for all IS-IS Sub-TLVs registered in the
252   IS-IS Sub-TLVs Advertising Prefix Reachability registry, which was
253   initially defined in [RFC7370], e.g.,:

For clarity, I would suggest:

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


272   level 1 and level 2.  Propagation is only done if the prefix is
273   reachable in the source level, e.g., prefix is only propagated from a

s/e.g.,/i.e.,


315   UPA in OSPFv2 is supported for OSPFv2 Summary-LSA [RFC2328], AS-
316   external-LSAs [RFC2328], NSSA AS-external LSA [RFC3101], and OSPFv2
317   IP Algorithm Prefix Reachability Sub-TLV [RFC9502].

I think the intention here is to say that "UPA in OSPFv2 is supported
for prefix reachability advertised via ..." ?


333 4.2.  Propagation of UPA in OSPF

335   OSPF ABRs or ASBRs, which would be responsible for propagating UPA
336   advertisements into other areas MUST recognize such advertisements.

This is more of a deployment guideline. Please see similar comment in
section 3.1


352   set in PrefixOptions, for various reasons.  Even though in all cases
353   the treatment of such metric, or NU-bit, is specified for IS-IS, OSPF
354   and OSPFv3, having an explicit way to signal that the prefix was
355   advertised in order to signal unreachability is required to

perhaps s/unreachability/UPA ?


382 5.2.  Signaling UPA in OSPF

384   A new Prefix Attributes Sub-TLV has been defined in
385   [I-D.ietf-lsr-ospf-prefix-extended-flags] for advertising additional
386   prefix attribute flags in OSPFv2 and OSPFv3.

please update reference to RFC9792 and also "OSPFv2 and OSPFv3
Prefix Attributes sub-TLVs have been ..."


403 5.2.1.  Signaling UPA in OSPFv2

405   In OSPFv2 the Prefix Attributes Sub-TLV is a Sub-TLV of the OSPFv2
406   Extended Prefix TLV [RFC7684].

The name is "OSPFv2 Prefix Attributes Sub-TLV"


428   metric set to a value LSInfinity.  For default algorithm 0 prefixes,
429   the LSInfinity MUST be set in the parent TLV.  For IP Algorithm
430   Prefixes [RFC9502], the LSInfinity MUST be set in OSPFv3 IP Algorithm
431   Prefix Reachability sub-TLV.  If the prefix metric is not equal to
432   LSInfinity, both of these flags MUST be ignored.

For OSPFv3, RFC9502 is clear about what metric is in operation. Is
this text on default and IP algo needed?


444   prefix.  As a result, depending on which ABR or ASBR the traffic is
445   using to enter a partitioned area, the traffic could be dropped or be
446   delivered to its final destination.  UPA does not make the problem of

could be either dropped or delivered ...


460 7.  Processing of the UPA

462   The setting of the U-Flag signals that the prefix is unreachable.  If
463   the U flag is set, the setting of the UP flag signals that the
464   unreachability is due to a planned event.

Suggest to move the above paragraph at the end of section 5 and just
before section 5.1 where the semantics of the flags would be introduced before
their protocol encodings are specified.


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

registries

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-lsr-igp-ureach-prefix-announce-09
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Yingzhen Qu for the shepherd's detailed write-up including the WG consensus (important to note for this I-D) _but it lacks_ the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### Title

s/IGP Unreachable Prefix Announcement/Unreachable Prefix *IGP* Announcement/ sounds clearer to me but English is not my primary language.

### Abstract

s/This document describes/This document *specifies*/ as this is proposed standard.

### Section 1

Who is the "we" in `we want to signal unreachability` ? The authors ? The LSR WG ? The IETF ? Please avoid using ambiguous "we" by rephrasing the sentence.

s/ISIS/IS-IS/ ? and in other places.

### Section 2

s/for a prefix that is summarized by the summary *address*/for a prefix that is summarized by the summary *prefix*/ ?

There are two "SHOULD" in this section but nothing is written the cases when these "SHOULD" can be bypassed and/or what are the consequences.

Add "and OSPFv3" at the end of `so the above optimisation does not apply to OSPF` ? It seems that the I-D sometimes uses OSPF for OSPFv2 alone and sometimes for OSPFv2 and OSPFv3.

### Section 3.1

Add "to support this specification" after `without the need to upgrade all nodes in a network.` ?

`Those ABRs or ASBRs, which are responsible for propagating UPA advertisements into other areas or domains MUST also recognize UPA advertisements.` what are the consequences if this is not the case (e.g., not all ABR/ASBR have been upgraded). Should this be mentioned in an operational considerations section ?

### Section 5.1

Was the use of a 2-bit field considered rather than using 2 flags ? It would have allowed 4 values as opposed as the current 3 values. Out of curiosity because it is probably too late to change it...

### Section 8

It is often preferable to add an informational reference to the URI of the registries.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-lsr-igp-ureach-prefix-announce-08. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are three actions which we must complete.

First, in the IS-IS Bit Values for Prefix Attribute Flags Sub-TLV registry in the IS-IS TLV Codepoints registry group located at:

https://www.iana.org/assignments/isis-tlv-codepoints/

two early allocations will be made permanent and their references changed to [ RFC-to-be ] as follows:

Bit #: 5
Description: U-Flag
Reference: [ RFC-to-be; Section 5.1]

Bit #: 6
Description: UP-Flag
Reference: [ RFC-to-be; Section 5.1]

Second, in the OSPFv2 Prefix Extended TLV Flag Field registry in the Open Shortest Path First v2 (OSPFv2) Parameters registry group located at:

https://www.iana.org/assignments/ospfv2-parameters/

two early allocations will be made permanent and their references changed to [ RFC-to-be ] as follows:

Bit #: 0
Description: U-Flag
Reference: [ RFC-to-be; Section 5.2]

Bit #: 1
Description: UP-Flag
Reference: [ RFC-to-be; Section 5.2]

Third, in the OSPFv3 Prefix Extended Flags registry in the Open Shortest Path First v3 (OSPFv3) Parameters registry group located at:

https://www.iana.org/assignments/ospfv3-parameters/

two early allocations will be made permanent and their references changed to [ RFC-to-be ] as follows:

Bit #: 0
Description: U-Flag
Reference: [ RFC-to-be; Section 5.2]

Bit #: 1
Description: UP-Flag
Reference: [ RFC-to-be; Section 5.2]

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-06-24):

From: The IESG
To: IETF-Announce
CC: draft-ietf-lsr-igp-ureach-prefix-announce@ietf.org, james.n.guichard@futurewei.com, lsr-chairs@ietf.org, lsr@ietf.org, yingzhen.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (IGP Unreachable Prefix Announcement) to Proposed Standard


The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'IGP Unreachable Prefix Announcement'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-06-24. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Summarization is often used in multi-area or multi-domain networks to
  improve network efficiency and scalability.  With summarization in
  place, there is a need to signal loss of reachability to an
  individual prefix covered by the summary.  This enables fast
  convergence by steering traffic away from the node which owns the
  prefix and is no longer reachable.

  This document describes how to use the existing protocol mechanisms
  in IS-IS and OSPF, together with the two new flags, to advertise such
  prefix reachability loss.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-ureach-prefix-announce/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/6079/

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

During both the adoption call and the WGLC, this draft has gone through long
discussions. The majority of the WG agrees with solution.
WGLC:
https://mailarchive.ietf.org/arch/msg/lsr/bsYFz_k56K_6_pzEudA58SHqvjw/
Adoption call:
https://mailarchive.ietf.org/arch/msg/lsr/Tyo0-puL8In1Swj-mYdtj0gc1qw/
There are other long discussion threads on the LSR mailing list archive.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

1)
During the WGLC, there was objection from Tony Li and John Drake. They
think the problem shouldn't be solved using IGP:
https://mailarchive.ietf.org/arch/msg/lsr/298QAjMcDSuS9fEgx8eMgfBMNN0/
https://mailarchive.ietf.org/arch/msg/lsr/84A3IqPRvOMih7wofaDfc0290r8/

2)
Aijun Wang is objecting:
https://mailarchive.ietf.org/arch/msg/lsr/dqBcKdfJlyZiJ_N0QSxq2fhdLIY/
https://mailarchive.ietf.org/arch/msg/lsr/BRSv68IUdiN88IVW-9LDDWDWF3g/

During the WGLC, Aijun repeatly raised the same issue which was discussed
many times during the LC, even during the WG adoption.

Warning emails from the LSR chairs regarding inappropriate behaviors:
https://mailarchive.ietf.org/arch/msg/lsr/mEOWwwydQVrgbbtb6yGGn-Y1-u8/
https://mailarchive.ietf.org/arch/msg/lsr/HNEWH-giTuBZ8XAZLNYgfxchBJY/
https://mailarchive.ietf.org/arch/msg/lsr/-9yOhp4Xy-nwseZW2yfxJZG1F_A/


3)
Despite Aijun has sent multiple emails to the list asking the same questions
many times, he put together a draft to document his objections:
https://datatracker.ietf.org/doc/draft-wang-lsr-reasons-of-abandon-upa-proposal/

Here are answers to his objections:
"2.  LSInfinity Feature is Flawed"
In section 2 of his draft, he claims the base OSPF protocol RFC 2328 is flawed.
He asked the same question on the list and it had been answered multiple times:
https://mailarchive.ietf.org/arch/msg/lsr/meYkPGshtGdU0D0Yxi7ei5oiH_g/
The protocol is working as designed.

"3.  U/UP Flag Definitiaon should be Removed"
The adding of these flags was WG consensus, please refer to this email as an
example of discussion about these flags:
https://mailarchive.ietf.org/arch/msg/lsr/WN6x192LtVj5E_03GN7eDasO0YA/

"4.  Mimic Parts should be Removed"
The WG acknowledges that Aijun's contribution to the problem statement, and the
authors of this document recognized him as a contributor.
Regarding the history of draft-ietf-lsr-igp-ureach-prefix-announce, the
following email from Peter can be referenced:
https://mailarchive.ietf.org/arch/msg/lsr/WGpVq1GLDKKqXgH4FwhiBvgyvmU/

"4.1.  Control Knob at the ABR"
It's a common practice in routing protocols to add configuration knobs. It's not
innovative.

"4.2.  Partitiion Consideration"
It is clearly stated in the document that "UPA is not meant to address an
area/domain partition", and "UPA does not make the problem of an area partition
any worse.".
An example email (there are multiple of them) to answer Aijun's question:
https://mailarchive.ietf.org/arch/msg/lsr/uZbtk1CFFGTt2CquSHZN1tutnhU/

In summary, all his objections has been answered multiple times from the list.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

Yes. Aijun Wang sent an email to the list and the responsible AD for a potential
appeal on May 15th, 2025:
https://mailarchive.ietf.org/arch/msg/lsr/ylWpF35cAizqR5hJxgKYXaRUl-A/
The AD has acknowleged receving of his email:
https://mailarchive.ietf.org/arch/msg/lsr/vsENM0BkYCQttP7QwNh9GkoQYDk/
Response from the responsible AD:
https://mailarchive.ietf.org/arch/msg/lsr/cXuwrL3n1AK8cpighzHj1DeSQyQ/

Please note that Aijun had requested the AD to step in during the adoption call,
and here is the response from John Scudder (responsible AD at the time):
https://mailarchive.ietf.org/arch/msg/lsr/P6nKRoztoxsq9ognWGc14ocELGY/


4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, multi vendors. There are known implementations of the mechanism
defined in this document.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

N/A

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Routing Directorate review comments addressed:
https://mailarchive.ietf.org/arch/msg/lsr/t9z94N00FPBy7gWOy-fh6wuN1As/
OPS directorate review:
https://mailarchive.ietf.org/arch/msg/lsr/caItCT6CCi4APnAarjHwv3_eHtU/
Security directorate reviews has been requested.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes - I've reviewed the document multiple times.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The IETF stream is Proposed Standard. This is correct and the Datatracker reflects this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. An IPR call was answered by all authors and contributors during the WGLC.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The author list had been reduced to five authors and they all have contributed
to the document.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All the document nits have been addressed.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16]

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section and new code points have been reviewed.
This document requests IANA to add two new bits in the "IS-IS Bit Values for Prefix
Attribute Flags Sub-TLV" registry which have been done through early allocation, two
new bits in the "OSPFv2 Prefix Extended TLV Flag Field" and "OSPFv3 Prefix Extended
TLV Flag Field" registries which are still to be allocated.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

Only the ISIS registries require expert review, and it already has designated experts assigned.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]:
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

IETF IESG IAB IRTF IETF LLC IETF Trust RFC Editor IANA Privacy Statement
About IETF Datatracker Version 12.40.0 (release - a04c432) System Status  Report a bug: GitHub Email

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

During both the adoption call and the WGLC, this draft has gone through long
discussions. The majority of the WG agrees with solution.
WGLC:
https://mailarchive.ietf.org/arch/msg/lsr/bsYFz_k56K_6_pzEudA58SHqvjw/
Adoption call:
https://mailarchive.ietf.org/arch/msg/lsr/Tyo0-puL8In1Swj-mYdtj0gc1qw/
There are other long discussion threads on the LSR mailing list archive.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

1)
During the WGLC, there was objection from Tony Li and John Drake. They
think the problem shouldn't be solved using IGP:
https://mailarchive.ietf.org/arch/msg/lsr/298QAjMcDSuS9fEgx8eMgfBMNN0/
https://mailarchive.ietf.org/arch/msg/lsr/84A3IqPRvOMih7wofaDfc0290r8/

2)
Aijun Wang is objecting:
https://mailarchive.ietf.org/arch/msg/lsr/dqBcKdfJlyZiJ_N0QSxq2fhdLIY/
https://mailarchive.ietf.org/arch/msg/lsr/BRSv68IUdiN88IVW-9LDDWDWF3g/

During the WGLC, Aijun repeatly raised the same issue which was discussed
many times during the LC, even during the WG adoption.

Warning emails from the LSR chairs regarding inappropriate behaviors:
https://mailarchive.ietf.org/arch/msg/lsr/mEOWwwydQVrgbbtb6yGGn-Y1-u8/
https://mailarchive.ietf.org/arch/msg/lsr/HNEWH-giTuBZ8XAZLNYgfxchBJY/
https://mailarchive.ietf.org/arch/msg/lsr/-9yOhp4Xy-nwseZW2yfxJZG1F_A/


3)
Despite Aijun has sent multiple emails to the list asking the same questions
many times, he put together a draft to document his objections:
https://datatracker.ietf.org/doc/draft-wang-lsr-reasons-of-abandon-upa-proposal/

Here are answers to his objections:
"2.  LSInfinity Feature is Flawed"
In section 2 of his draft, he claims the base OSPF protocol RFC 2328 is flawed.
He asked the same question on the list and it had been answered multiple times:
https://mailarchive.ietf.org/arch/msg/lsr/meYkPGshtGdU0D0Yxi7ei5oiH_g/
The protocol is working as designed.

"3.  U/UP Flag Definitiaon should be Removed"
The adding of these flags was WG consensus, please refer to this email as an
example of discussion about these flags:
https://mailarchive.ietf.org/arch/msg/lsr/WN6x192LtVj5E_03GN7eDasO0YA/

"4.  Mimic Parts should be Removed"
The WG acknowledges that Aijun's contribution to the problem statement, and the
authors of this document recognized him as a contributor.
Regarding the history of draft-ietf-lsr-igp-ureach-prefix-announce, the
following email from Peter can be referenced:
https://mailarchive.ietf.org/arch/msg/lsr/WGpVq1GLDKKqXgH4FwhiBvgyvmU/

"4.1.  Control Knob at the ABR"
It's a common practice in routing protocols to add configuration knobs. It's not
innovative.

"4.2.  Partitiion Consideration"
It is clearly stated in the document that "UPA is not meant to address an
area/domain partition", and "UPA does not make the problem of an area partition
any worse.".
An example email (there are multiple of them) to answer Aijun's question:
https://mailarchive.ietf.org/arch/msg/lsr/uZbtk1CFFGTt2CquSHZN1tutnhU/

In summary, all his objections has been answered multiple times from the list.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

Yes. Aijun Wang sent an email to the list and the responsible AD for a potential
appeal on May 15th, 2025:
https://mailarchive.ietf.org/arch/msg/lsr/ylWpF35cAizqR5hJxgKYXaRUl-A/
The AD has acknowleged receving of his email:
https://mailarchive.ietf.org/arch/msg/lsr/vsENM0BkYCQttP7QwNh9GkoQYDk/

Please note that Aijun had requested the AD to step in during the adoption call,
and here is the response from John Scudder (responsible AD at the time):
https://mailarchive.ietf.org/arch/msg/lsr/P6nKRoztoxsq9ognWGc14ocELGY/


4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, multi vendors. There are known implementations of the mechanism
defined in this document.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

N/A

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

A Routing Directorate, OPS directorate and Security directorate reviews have
been requested.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes - I've reviewed the document multiple times.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The IETF stream is Proposed Standard. This is correct and the Datatracker reflects this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. An IPR call was answered by all authors and contributors during the WGLC.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The author list had been reduced to five authors and they all have contributed
to the document.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All the document nits have been addressed.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16]

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section and new code points have been reviewed.
This document requests IANA to add two new bits in the "IS-IS Bit Values for Prefix
Attribute Flags Sub-TLV" registry which have been done through early allocation, two
new bits in the "OSPFv2 Prefix Extended TLV Flag Field" and "OSPFv3 Prefix Extended
TLV Flag Field" registries which are still to be allocated.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

Only the ISIS registries require expert review, and it already has designated experts assigned.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]:
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

IETF IESG IAB IRTF IETF LLC IETF Trust RFC Editor IANA Privacy Statement
About IETF Datatracker Version 12.40.0 (release - a04c432) System Status  Report a bug: GitHub Email

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

During both the adoption call and the WGLC, this draft has gone through long
discussions. The majority of the WG agrees with solution.
WGLC:
https://mailarchive.ietf.org/arch/msg/lsr/bsYFz_k56K_6_pzEudA58SHqvjw/
Adoption call:
https://mailarchive.ietf.org/arch/msg/lsr/Tyo0-puL8In1Swj-mYdtj0gc1qw/
There are other long discussion threads on the LSR mailing list archive.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

1)
During the WGLC, there was objection from Tony Li and John Drake. They
think the problem shouldn't be solved using IGP:
https://mailarchive.ietf.org/arch/msg/lsr/298QAjMcDSuS9fEgx8eMgfBMNN0/
https://mailarchive.ietf.org/arch/msg/lsr/84A3IqPRvOMih7wofaDfc0290r8/

2)
Aijun Wang is objecting:
https://mailarchive.ietf.org/arch/msg/lsr/dqBcKdfJlyZiJ_N0QSxq2fhdLIY/
https://mailarchive.ietf.org/arch/msg/lsr/BRSv68IUdiN88IVW-9LDDWDWF3g/

During the WGLC, Aijun repeatly raised the same issue which was discussed
many times during the LC, even during the WG adoption.

Warning emails from the LSR chairs regarding inappropriate behaviors:
https://mailarchive.ietf.org/arch/msg/lsr/mEOWwwydQVrgbbtb6yGGn-Y1-u8/
https://mailarchive.ietf.org/arch/msg/lsr/HNEWH-giTuBZ8XAZLNYgfxchBJY/
https://mailarchive.ietf.org/arch/msg/lsr/-9yOhp4Xy-nwseZW2yfxJZG1F_A/


3)
Despite Aijun has sent multiple emails to the list asking the same questions
many times, he put together a draft to document his objections:
https://datatracker.ietf.org/doc/draft-wang-lsr-reasons-of-abandon-upa-proposal/

Here are answers to his objections:
"2.  LSInfinity Feature is Flawed"
In section 2 of his draft, he claims the base OSPF protocol RFC 2328 is flawed.
He asked the same question on the list and it had been answered multiple times:
https://mailarchive.ietf.org/arch/msg/lsr/meYkPGshtGdU0D0Yxi7ei5oiH_g/
The protocol is working as designed.

"3.  U/UP Flag Definitiaon should be Removed"
The adding of these flags was WG consensus, please refer to this email as an
example of discussion about these flags:
https://mailarchive.ietf.org/arch/msg/lsr/WN6x192LtVj5E_03GN7eDasO0YA/

"4.  Mimic Parts should be Removed"
The WG acknowledges that Aijun's contribution to the problem statement, and the
authors of this document recognized him as a contributor.
Regarding the history of draft-ietf-lsr-igp-ureach-prefix-announce, the
following email from Peter can be referenced:
https://mailarchive.ietf.org/arch/msg/lsr/WGpVq1GLDKKqXgH4FwhiBvgyvmU/

"4.1.  Control Knob at the ABR"
It's a common practice in routing protocols to add configuration knobs. It's not
innovative.

"4.2.  Partitiion Consideration"
It is clearly stated in the document that "UPA is not meant to address an
area/domain partition", and "UPA does not make the problem of an area partition
any worse.".
An example email (there are multiple of them) to answer Aijun's question:
https://mailarchive.ietf.org/arch/msg/lsr/uZbtk1CFFGTt2CquSHZN1tutnhU/

In summary, all his objections has been answered multiple times from the list.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

Yes. Aijun Wang sent an email to the list and the responsible AD for a potential
appeal on May 15th, 2025:
https://mailarchive.ietf.org/arch/msg/lsr/ylWpF35cAizqR5hJxgKYXaRUl-A/
The AD has acknowleged receving of his email:
https://mailarchive.ietf.org/arch/msg/lsr/vsENM0BkYCQttP7QwNh9GkoQYDk/

Please note that Aijun had requested the AD to step in during the adoption call,
and here is the response from John Scudder (responsible AD at the time):
https://mailarchive.ietf.org/arch/msg/lsr/P6nKRoztoxsq9ognWGc14ocELGY/


4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, multi vendors. There are known implementations of the mechanism
defined in this document.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

N/A

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

A Routing Directorate, OPS directorate and Security directorate reviews have
been requested.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes - I've reviewed the document multiple times.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The IETF stream is Proposed Standard. This is correct and the Datatracker reflects this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. An IPR call was answered by all authors and contributors during the WGLC.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The author list had been reduced to five authors and they all have contributed
to the document.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All the document nits have been addressed.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16]

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section and new code points have been reviewed.
This document requests IANA to add two new bits in the "IS-IS Bit Values for Prefix
Attribute Flags Sub-TLV" registry which have been done through early allocation, two
new bits in the "OSPFv2 Prefix Extended TLV Flag Field" and "OSPFv3 Prefix Extended
TLV Flag Field" registries which are still to be allocated.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

Only the ISIS registries require expert review, and it already has designated experts assigned.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]:
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

IETF IESG IAB IRTF IETF LLC IETF Trust RFC Editor IANA Privacy Statement
About IETF Datatracker Version 12.40.0 (release - a04c432) System Status  Report a bug: GitHub Email

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

During both the adoption call and the WGLC, this draft has gone through long
discussions. The majority of the WG agrees with solution.
WGLC:
https://mailarchive.ietf.org/arch/msg/lsr/bsYFz_k56K_6_pzEudA58SHqvjw/
Adoption call:
https://mailarchive.ietf.org/arch/msg/lsr/Tyo0-puL8In1Swj-mYdtj0gc1qw/
There are other long discussion threads on the LSR mailing list archive.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

1)
During the WGLC, there was objection from Tony Li and John Drake. They
think the problem shouldn't be solved using IGP:
https://mailarchive.ietf.org/arch/msg/lsr/298QAjMcDSuS9fEgx8eMgfBMNN0/
https://mailarchive.ietf.org/arch/msg/lsr/84A3IqPRvOMih7wofaDfc0290r8/

2)
Aijun Wang is objecting:
https://mailarchive.ietf.org/arch/msg/lsr/dqBcKdfJlyZiJ_N0QSxq2fhdLIY/
https://mailarchive.ietf.org/arch/msg/lsr/BRSv68IUdiN88IVW-9LDDWDWF3g/

During the WGLC, Aijun repeatly raised the same issue which was discussed
many times during the LC, even during the WG adoption.

Warning emails from the LSR chairs regarding inappropriate behaviors:
https://mailarchive.ietf.org/arch/msg/lsr/mEOWwwydQVrgbbtb6yGGn-Y1-u8/
https://mailarchive.ietf.org/arch/msg/lsr/HNEWH-giTuBZ8XAZLNYgfxchBJY/
https://mailarchive.ietf.org/arch/msg/lsr/-9yOhp4Xy-nwseZW2yfxJZG1F_A/


3)
Despite Aijun has sent multiple emails to the list asking the same questions
many times, he put together a draft to document his objections:
https://datatracker.ietf.org/doc/draft-wang-lsr-reasons-of-abandon-upa-proposal/

Here are answers to his objections:
"2.  LSInfinity Feature is Flawed"
In section 2 of his draft, he claims the base OSPF protocol RFC 2328 is flawed.
He asked the same question on the list and it had been answered multiple times:
https://mailarchive.ietf.org/arch/msg/lsr/meYkPGshtGdU0D0Yxi7ei5oiH_g/
The protocol is working as designed.

"3.  U/UP Flag Definitiaon should be Removed"
The adding of these flags was WG consensus, please refer to this email as an
example of discussion about these flags:
https://mailarchive.ietf.org/arch/msg/lsr/WN6x192LtVj5E_03GN7eDasO0YA/

"4.  Mimic Parts should be Removed"
The WG acknowledges that Aijun's contribution to the problem statement, and the
authors of this document recognized him as a contributor.
Regarding the history of draft-ietf-lsr-igp-ureach-prefix-announce, the
following email from Peter can be referenced:
https://mailarchive.ietf.org/arch/msg/lsr/WGpVq1GLDKKqXgH4FwhiBvgyvmU/

"4.1.  Control Knob at the ABR"
It's a common practice in routing protocols to add configuration knobs. It's not
innovative.

"4.2.  Partitiion Consideration"
It is clearly stated in the document that "UPA is not meant to address an
area/domain partition", and "UPA does not make the problem of an area partition
any worse.".
An example email (there are multiple of them) to answer Aijun's question:
https://mailarchive.ietf.org/arch/msg/lsr/uZbtk1CFFGTt2CquSHZN1tutnhU/

In summary, all his objections has been answered multiple times from the list.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

Yes. Aijun Wang sent an email to the list and the responsible AD for a potential
appeal on May 15th, 2025:
https://mailarchive.ietf.org/arch/msg/lsr/ylWpF35cAizqR5hJxgKYXaRUl-A/
The AD has acknowleged receving of his email:
https://mailarchive.ietf.org/arch/msg/lsr/vsENM0BkYCQttP7QwNh9GkoQYDk/

Please note that Aijun had requested the AD to step in during the adoption call,
and here is the response from John Scudder (responsible AD at the time):
https://mailarchive.ietf.org/arch/msg/lsr/P6nKRoztoxsq9ognWGc14ocELGY/


4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, multi vendors. There are known implementations of the mechanism
defined in this document.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

N/A

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

A Routing Directorate, OPS directorate and Security directorate reviews have
been requested.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes - I've reviewed the document multiple times.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The IETF stream is Proposed Standard. This is correct and the Datatracker reflects this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. An IPR call was answered by all authors and contributors during the WGLC.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The author list had been reduced to five authors and they all have contributed
to the document.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All the document nits have been addressed.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16]

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section and new code points have been reviewed.
This document requests IANA to add two new bits in the "IS-IS Bit Values for Prefix
Attribute Flags Sub-TLV" registry, two new bits in the "OSPFv2 Prefix Extended TLV
Flag Field" and "OSPFv3 Prefix Extended TLV Flag Field" registries.



21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

All registries already have designated experts assigned.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]:
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

IETF IESG IAB IRTF IETF LLC IETF Trust RFC Editor IANA Privacy Statement
About IETF Datatracker Version 12.40.0 (release - a04c432) System Status  Report a bug: GitHub Email

Request for posting confirmation emailed to previous authors: Clarence Filsfils , Dan Voyer , Dhamija , Gunter Van de Velde , Gyan Mishra , Peter Psenak , Shraddha Hegde , Stephane Litkowski , lsr-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Clarence Filsfils , Dan Voyer , Dhamija , Gunter Van de Velde , Gyan Mishra , Peter Psenak , Shraddha Hegde , Stephane Litkowski

Request for posting confirmation emailed to previous authors: Clarence Filsfils , Dan Voyer , Dhamija , Gunter Van de Velde , Gyan Mishra , Peter Psenak , Shraddha Hegde , Stephane Litkowski , lsr-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Clarence Filsfils , Dan Voyer , Dhamija , Gunter Van de Velde , Gyan Mishra , Peter Psenak , Shraddha Hegde , Stephane Litkowski