Hi Dale,
thank you for your comments, please see responses inline (look for ##PP):
I have updated the draft and attached the diffs.
On 24/06/2025 19:57, Dale Worley via Datatracker wrote:
Document: draft-ietf-lsr-igp-ureach-prefix-announce
Title: IGP Unreachable Prefix Announcement
Reviewer: Dale Worley
Review result: Ready with Issues
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.
Document: draft-ietf-lsr-igp-ureach-prefix-announce-08
Reviewer: Dale R. Worley
Review Date: 2025-06-24
IETF LC End Date: 2025-06-24
IESG Telechat date: [not known]
Summary:
This draft is on the right track but has open issues, described in
the review.
As far as I can tell, the proposed mechanism is sound as a solution to
the stated problem. But I am not a routing expert. However, the
document needs improved organization as an exposition of the
mechanism. It seems like the current version would be sufficient for
a routing expert to implement the mechanism but it lacks the clarity
needed for either a standards definition or for non-expert readers.
##PP
I appreciate your effort to make the document more readable for the
non-experts,
but I'm afraid, some level of routing expertise would still be
required from the reader.
We are building on existing RFCs and a familiarity with those is
expected. But I'll try
to make easier to read.
Major issues:
It would help if the earlier parts of the document (that is, sections
1 and 2, before the specifics of IS-IS and OSPF usage are introduced)
explained the mechanism conceptually. In particular, it would be
helpful to have a direct statement of the significance of the U and UP
bits, independent of how the bits are implemented in each routing
protocol. E.g.
A UPA announcement is indicated by attaching the U bit to the
announcement of a prefix, which thus indicates that the prefix is
unreachable. A UPA may also have the UP bit attached, indicating that
the unreachability is due to a planned event. How the U and UP bits
are attached to a prefix is dependent on the routing protocol and is
described later.
##PP:
This document does NOT define how to advertise prefix unreachability.
That has been defined long time back in RFC5305, RFC2328, and RFC5340.
This document only defines a method to signal WHY the explicit unreachability
is sent,
to distinguish it from any other possible cases, where sending explicit
unreachability
may be used. Please note that protocols typically just stop advertising the
prefix
reachability, which makes the previously advertised prefix unreachable.
Here the use case is to signal unreachability for a prefix for which
the previous reachability was not explicitly signaled, because it was covered
by the reachability of the summary-address.
In the earlier parts of the document, the phrase "the protocol
specific maximum prefix metric" is used in many places. However, it
appears that this does not necessarily mean a specific value in the
metric field of the protocol, nor is the value necessarily the one
descried as "the maximum metric" in the routing protocol definition.
For instance, it appears that the condition for IS-IS is:
a prefix is advertised with a metric larger then MAX_PATH_METRIC
(0xFE000000)
##PP
"the protocol specific maximum prefix metric" is used in two places.
There are two different thing that the document refers to:
a) metric used when advertising unreachability - e.g. in case of ISIS
metric higher than 0xFE000000 , in case of OSPFv3 LSInfinity, and in
case of OSPFV3 it's the NU-bit
b) "the protocol specific maximum prefix metric", which is not the
metric used for UPA itself. It is the maximum reachable prefix metric
protocols allow to advertise, e.g. 0xFE000000 for ISIS.
To avoid the confusion, I will replace the "the protocol specific
maximum prefix metric" , by the "user configured protocol metric
threshold", which would be much more clear and also flexible in terms
of when the UPA can be generated.
(Note that the metric value that indicates unreachability is greater
than the one described as "maximum path metric"!) And for OSPF:
a prefix that has the age set to a value lower than MaxAge and
metric set to LSInfinity
or possibly
a prefix having the NU-bit set.
(The situation for OSPF is not at all clear, there seem to be multiple
indications of unreachability; see below for more details.)
If I am correct, you want to define a term like "the protocol specific
way of specifying unreachability". Then you want to state early in
the document something like
A router that implements UPA MUST attach the U-bit to any
announcement that contains the protocol specific way of specifying
unreachability. Conversely, any announcement with the U-bit MUST also
include the protocol specific way of specifying unreachability.
##PP
advertisement of the prefix unreachability has been defined in the
past and we
are not allowed to change it, as that would result in a backward
compatibility issue.
So we can not mandate any new-bit for signaling the unreachability. We
are just
indicating with the optional new flags the reason why the
unreachbaility was advertised.
The goal is to give a complete *conceptual* description of the UPA
mechanism in sections 1 and 2, and then provide the details of its
implementation in IS-IS and OSPF in sections 3, 4, and 5.
##PP
let me add some additional clarification text, possibly from my
responses above, to see if that would make you fell better about it.
There are a considerable number of places in the document where
all-caps normative words should be used. I have noted some of these
below. And almost all uses of the subjunctive "would" should be
replaced by more definitive wording.
##PP
I have respond to individual case below
Minor issues:
Nits/editorial comments:
Some flag bits are described as "bits" and some as "flags", and the
capitalization is not consistent. In the document I see
NU-bit
OL-bit
U-Flag
UP-Flag
These should be made consistent.
##PP
NU-bit is the name from OSPFv3 Prefix Options registry
OL-bit ISO10589 ras well as RFC5120 refer to it as bit, I will
replace it with OVERLOAD bit to be consistent with RFC5120.
U-flag and UP-flag are defined in:
"IS-IS Bit Values for Prefix Attribute Flags Sub-TLV"
"OSPFv2 Prefix Extended Flags"
"OSPFv3 Prefix Extended Flags"
all of the above registries use "flag", rather than bit. So we are
consistent to the degree possible I believe.
1. Introduction
... OSPFV3 ...
Comparing with RFC 5340, that probably should be spelled "OSPFv3".
##PP
absolutely, fixed it.
Similarly, when an egress router needs to be taken out for
Perhaps "taken out of service".
##PP
fixed it.
the ABR/ASBR
It might be useful to expand this acronym or give a phrase explaining
what it is/does. "ABR" is used frequently in the document, but the
first explanation is in section 4.1.
##PP
done
This document proposes protocol
extensions to carry information about such prefixes in a backward
compatible manner.
"such prefixes" is vague here. Perhaps "prefixes in the area which
are not reachable".
##PP
replaced with "these summarized prefixes"
This document defines two new flags in IS-IS and OSPF.
It seems to me that the introduction should include some further
description of the flags, as at this point, I have no idea what the
flags mean. At this point in my reading, I *think* the description
is, "This document defines two new flags. One flag is applied to
prefixes listed in announcements to the outside world by an ABR to
indicate that the prefix is not reachable. The second flag indicates
that a prefix is unreachable due to a planned event."
##PP
the definition of these flags are in section 5.1 and 5.2.
The definition of these flags are not tight to the ABR role. They may
be used elsewhere in the future if the use case arises.
These flags,
together with the existing protocol mechanisms, provide the support
for the necessary functionality.
Better "provide what is needed to support this functionality". (The
"functionality" itself is not "necessary", as no routers have this
functionality today.)
##PP
again, we are coming back to the fact that the functionality exists today,
we are only defining a way to signal WHY we are using it.
I have updated the text, let me know if you agree.
2. Generation of the UPA
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:
1. Reachability of a prefix that was reachable earlier was lost.
2. For planned maintenance if the node originating the prefix is
signalling the overload state in ISIS, or if the prefix itself is
advertised with the protocol specific maximum prefix metric.
When the ABR/ASBR does so, it MAY set the UP bit to indicate
that.
ISTM that case 2 has two or possibly three parts, and so it would be
better to say
1. Reachability of a prefix that was reachable earlier was lost.
2. For planned maintenance.
3. If the node originating the prefix is
signalling the overload state in IS-IS.
[hyphenate IS-IS here]
4. If the prefix itself is
advertised with the protocol specific maximum prefix metric.
When the ABR/ASBR does so, it MAY set the UP bit to indicate
that.
##PP
no, 3 and 4 are part of planned maintenance case, that's why they are
bundled in (2).
I have split the bullet 2 to multiple sub-bullets to make it clear.
And it's not clear to me whether that last sentence is part of case 4
or applies to all cases.
But case 4 is unclear in regard to who is advertising the prefix with
max-metric. The second sentence suggests that this can be done in at
least two ways, one "when the ABR/ASBR does so", and one where another
unnamed advertiser does so. In any case, since this text talks about
the UP bit, the UP bit should have been introduced before this point.
##PP
well, some other reviewer asked me to move this section before the
protocol specific sections :)
So what I did is that I removed the reference to UP-bit in section 2,
it was not needed there.
Implementations are free to limit the UPA generation to specific
prefixes,
Why not use "Implementations MAY limit ..."?
##PP
done
ABR or ASBR MUST withdraw the previously advertised UPA when the
reason for which the UPA was generated was lost
Perhaps better, "reason for which the UPA was generated ceases".
##PP
done
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.
Probably clearer to say "dedicated to UPA advertisements", as well as
shorter.
##PP
the whole point of the above paragraph is to say that dedicated LSPs,
so I would rather use that explicit terminology.
3. Supporting UPA in IS-IS
(If sections 3 and 4 (not including their subsections) are intended
purely as background, it would be helpful to state that initially, as
when I was reading both of those sections, I kept trying to figure out
how the facts presented connected with the thread of the narrative.)
##PP
there are quotes from RFC5305 and RFC5308 about how to advertise the
prefix unreachability.
They also specify how to do that for the use case that we are trying
to address - e.g. summarization.
They also talk about the specifics of UPA propagation, that are new.
So it's not just a background.
This section gives a somewhat lengthy discussion of the
MAX_PATH_METRIC value. But it doesn't specifically say how that
interacts with the U/UP bits. I *think* the idea is that "the metric
is larger than MAX_PATH_METRIC" is the "protocol specific maximum
prefix metric", but of course, MAX_PATH_METRIC isn't that value,
instead all values larger than it (0xFE000001 to 0xFFFFFFFF) are
meant.
##PP
These are existing protocol definitions that we refer to.
And yes, existing RFC clearly states that any metric larger than
MAX_PATH_METRIC is considered unreachable.
This functionality can be used to advertise a prefix (IPv4 or IPv6)
in a manner which indicates that reachability has been lost - and to
do so without requiring all nodes in the network to be upgraded to
support the functionality.
I *think* the intention of this is that if a conforming router applies
the U-bit to a prefix, it should *also* apply a metric value larger
than MAX_PATH_METRIC so that the advertisement is understood as
indicating unreachability by routers that don't implement UPA. See
the discussion above.
##PP
again the new bits are to signal WHY the unreachability has been sent,
they are not meaning unreachability by themselves.
3.1. Advertisement of UPA in IS-IS
Area Border Routers
(ABRs), which would be responsible for propagating UPA advertisements
into other areas would need to recognize such advertisements.
Exactly which routers have a requirement are not clear. One meaning
is
Area Border Routers
(ABRs), which are responsible for propagating UPA advertisements
into other areas, MUST recognize such advertisements.
that is, all ABRs are responsible for propagating into other areas,
and so they all must recognize UPAs. But another meaning is
Those Area Border Routers
(ABRs) which are responsible for propagating UPA advertisements
into other areas MUST recognize such advertisements.
that is, a specific subset of ABRs. In either case, consider using
MUST rather than "need to".
##PP
good comment, changed it.
As per the definitions referenced in the preceding section, any
prefix advertisement with a metric value greater than 0xFE000000 can
be used for purposes other than normal routing calculations. Such
metric MUST be used when advertising UPA in IS-IS.
"purposes other than normal routing calculations" might include a very
wide range of semantics. The critical fact is that *all* such values
indicate the prefix is unreachable, or, perhaps, that *this* advertisement
does not indicate that the prefix is reachable. It would be clearer
to state it that way.
##PP
that terminology was taken from the RFC5308 and it was done
intentionally.
I would prefer to keep it as it gives the reader a clear reference to
the existing specification.
UPA in IS-IS is supported for all IS-IS Sub-TLVs Advertising Prefix
Reachability, e.g., ...
Comparing with RFC 9352 suggests you want to mention that "IS-IS
Sub-TLVs Advertising Prefix Reachability" is a defined registry
("initially defined in [RFC7370]") and then perhaps continuing with a
list of prominent members of the registry:
UPA in IS-IS is supported for all sub-TLVs registered in the IS-IS
Sub-TLVs Advertising Prefix Reachability registry, which was
initially defined in [RFC7370], e.g., ...
##PP
done
Importantly, if any sub-TLVs are added to the registry, UPA is
automatically applicable to them.
3.2. Propagation of UPA in IS-IS
IS-IS allows propagation of IP prefixes in both directions between
level 1 and level 2. For reachable prefixes this is only done if the
prefix is reachable in source level ...
Perhaps clearer as "reachable prefixes are only propagated from a
level in which the prefix is reachable." (If that is the correct
wording.)
##PP
done
4. Supporting UPA in OSPF
This section gives a lengthy discussion of LSInfinity, which is used
as a metric value, something called "premature aging", and the
NU-bit. All of these seem to be ways of indicating a prefix is
unreachable. But their interaction with UPA is not specified. In
particular, if an ABR implements UPA, which of these conditions
requires that the ABR add the U bit if it is not already present? And
for upward compatibility, if the ABR sets the U bit on an
advertisement, which of these mechanisms must also be applied to the
prefix?
##PP
I hope my previous responses made it clear.
4.1. Advertisement of UPA in OSPF
This section additionally mentions the condition "the age set to
value lower than MaxAge", which probably integrates with the
discussion in section 4 in some way.
Using the existing mechanism already defined in the standards, as
described in previous section, an advertisement of the inter-area or
external prefix inside OSPFv2 or OSPFv3 LSA that has the age set to
value lower than MaxAge and metric set to LSInfinity MUST be used
when advertising UPA.
This sentence is hard to read, as the essential condition is given
only at the very end. Better would be:
If an ABR advertises UPA in an advertisement of an inter-area 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.
##PP
done
4.2. Propagation of UPA in OSPF
OSPF Area Border Routers (ABRs), which would be responsible for
propagating UPA advertisements into other areas would need to
recognize such advertisements.
Use normative words -- what does "would" mean here?
##PP
done
5. Signaling UPA
In IS-IS a prefix can be advertised with metric higher than
0xFE000000, in OSPF with metric LSInfinity, or in OSPFv3 with NU-bit
set in PrefixOptions, for various reasons. Even though in all cases
the treatment of such metric, or NU-bit, is specified for IS-IS, OSPF
and OSPFv3, having an explicit way to signal that the prefix was
advertised in order to signal unreachability is required to
distinguish it from other cases where the prefix with such metric is
advertised.
If the metric is LSInfinity, that would seem to indicate definitively
that the prefix is unreachable. It would help to give some discussion
of what the "other cases" are.
##PP
there are none defined today, we are defining the first standardized "case" for
sending prefix with unreachable metric.
One can possibly advertise the prefix with unreachable metric and attach some
private TLVs to it.
Obviously these would be non-standard, but that was where the need for these
new bits started originally in the WG.
I have put some text around this in the section 1.
5.1. Signaling UPA in IS-IS
If the U-Flag is
not set, the UP-Flag MUST be ignored.
It seems to me that this holds for UPA generally, not just for IS-IS.
And that this is a situation where you want to be "strict in what you
send and lenient in what you accept". So put in the routing
protocol-independent sections at the beginning:
If an ABR does not set the U-Flag on a prefix, it MUST NOT set
the UP-flag. In a received advertisement, if the U-Flag is not
set on a prefix, the UP-Flag MUST be ignored.
##PP
done
5.2.2. Signaling UPA in OSPFv3
In OSPFv3 the Prefix Attribute Flags Sub-TLV is defined as a Sub-TLV
of the following OSPFv3 TLVs as defined in [RFC8362]:
Probably should be "that are defined in [RFC8362]", because "as they
are defined in [RFC8362]" they don't include Prefix Attribute Flags.
##PP
done
5.3. Treatement of the U-Flag and UP-Flag
The setting of the U-Flag or the UP-Flag signals that the prefix is
unreachable.
This is oddly phrased, given that if UP is set, U MUST be set. UP is
not an independent signal. Better to say "The setting of the U-Flag
signals that the prefix is unreachable." And then "If the U flag is
set, the setting of the UP flag signals that the unreachability is due
to a planned event." (It's not clear to me what use an ABR could make
of UP independently of U, but there likely are use cases I am not
aware of.) And indeed, this semantics should be stated in the routing
protocol independent part of the document.
##PP
I have removed the sentence. It was not correct anyway, because the
meaning of the bits have already defined earlier.
I have removed the entire section and updated the section 7.
Treatment of these
flags on the receiver is optional and the usage of them is outside of
scope of this document.
Clarify that the usage of the flags *by the receiver* is outside the
scope of this document, given that this entire document is about the
usage of these flags.
##PP
done in section 7
And given section 7, why is this stated here?
##PP
good point, above two responses should address this comment.
8.2. OSPFv2 and OSPFv3 Prefix Extended TLV Flag Field
This document adds two new bits in the "OSPFv2 Prefix Extended TLV
Flag Field" and "OSPFv3 Prefix Extended TLV Flag Field" registries:
These registries are named "OSPFv2 Prefix Extended Flags" and "OSPFv3
Prefix Extended Flags".
##PP
good catch, fixed.
9. Security Considerations
- [I-D.ietf-lsr-ospf-prefix-extended-flags] for both OSPFv2 and
OSPFv3.
Checking draft-ietf-lsr-igp-ureach-prefix-announce-08, its Security
Considerations is only
Procedures and protocol extensions defined in this document do not
affect the OSPFv2 or OSPFv3 security models. See the "Security
Considerations" Section of [RFC7684] for a discussion of OSPFv2 TLV-
encoding considerations, and the "Security Considerations" Section of
[RFC8362] for a discussion of OSPFv3 security.
It seems to me that you might as well include RFC 7684 and RFC 8362 in
the list of section 9 of the current document and omit referring to
draft-ietf-lsr-igp-ureach-prefix-announce.
##PP
I suppose you meant ietf-lsr-ospf-prefix-extended-flags.
It is now RFC9792, and I replaced the reference to it with reference
toRFC 7684 and RFC 8362 as you suggested
thanks, Peter
If
draft-ietf-lsr-igp-ureach-prefix-announce contains security
information beyond its Security Considerations referencing those RFCs,
it would be desirable to point that out explicitly here, as otherwise
the reader might follow this reference and only read the Security
Considerations of the referenced I-D.
[END]
