Hi Ketan,
I have posted the new version that incorporates all your comments,
thanks,
Peter
On 23/09/2025 12:55, Ketan Talaulikar wrote:
Hi Peter,
The text looks good to me. I'll clear my DISCUSS position once the
updated version is posted.
Thanks,
Ketan
On Tue, 23 Sept, 2025, 4:07 pm Peter Psenak, <[email protected]> wrote:
Hi Keatn,
please see inline (##PP3):
On 22/09/2025 18:06, Ketan Talaulikar wrote:
Hi Peter,
Only one point remains. Please check inline below for KT2.
On Mon, Sep 22, 2025 at 9:21 PM Peter Psenak <[email protected]>
wrote:
Hi Ketan,
please see inline (##PP2):
On 22/09/2025 15:43, Ketan Talaulikar wrote:
Hi Peter,
Thanks for your responses. Please check inline below for
follow-ups. Skipping the ones where we have reached an
agreement.
On Mon, Sep 22, 2025 at 6:20 PM Peter Psenak
<[email protected]> wrote:
Hi Ketan,
thanks for the comments, please see inline (##PP):
On 19/09/2025 19:49, Ketan Talaulikar via Datatracker wrote:
Ketan Talaulikar has entered the following ballot position for
draft-ietf-lsr-igp-ureach-prefix-announce-09: Discuss
When responding, please keep the subject line intact and reply to
all
email addresses included in the To and CC lines. (Feel free to cut
this
introductory paragraph, however.)
Please refer tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-ureach-prefix-announce/
----------------------------------------------------------------------
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?
##PP
For originating routers, section 2 says:
"UPA MAY be generated by the ABR or ASBR..".
I added a text in section 2:
"Generation of the UPA at the ABR or ASBR is optional
and SHOULD be controlled by
a configuration knob."
KT> This works for me, but consider "Generation and
propagation of the UPA ..." to also cover the next part?
##PP2
done
I would leave the default behavior for the
implementations to decide. I see no reason why an RFC
should mandate any specific default behavior.
For propagation, I would think that if the ABR supports
the UPA, it should propagate it. Implementations are
free to provide control if they wish to, but I see no
reason why an RFC should mandate that.
KT> Please see previous. I agree it is up to the
implementation - most likely it is the same knob for UPA
enablement as the propagating ABR might as well be the
originating ABR for its local area.
##PP2
I added "propagation"
For receiving routers, there is a text in section 7:
"Processing of the received UPAs is optional and SHOULD
be controlled by the configuration at the receiver."
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?
##PP
Implementations are free to provide all sorts of control
knobs, but from the UPA specification the only one that
are worth of specifying are the ones at the originating
and processing routers, which has been done.
KT> Section 2 has the following text:
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.
It is also RECOMMENDED that implementations limit the number
of UPA advertisements which can be originated at a given time.
I assume the reason for this is to ensure that in some
pathological cases, there is not a storm of UPAs or a large
number of UPAs being generated. If we consider access,
aggregation, and core layers, then at each progressive level
the propagation involves the UPAs of the lower level of
hierarchy being sent towards the core. In this case, the
propagating ABR/ASBRs are also kind of originating from the
UPAs from the lower layer in its LSAs/LSPs. So, shouldn't
the same controls/limits apply at those routers as well?
Perhaps consider tweaking the language in the above text to
cover both origination and propagation? I am not looking for
mention of specific knobs.
##PP2
added propagation to the above text.
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.
##PP
I'm not sure I understand the comment. Both extended
LSAs and Locator LSA are mentioned in the above quoted text.
The base OSPFv3 LSAs are NOT required, but if some
deployment uses the base LSAs only, they can be used to
signal UPA.
KT> First, if only the base OSPFv3 LSAs are used, we cannot
have the U/UP flags - if that is the intention, then please
specify. I would assume/expect that we want to use the
extended LSAs so those flags may be included. I also see it
as another motivation for implementing the extended LSAs ;-)
... since there is no real reachability, we can safely avoid
the duplicate advertisement of the base LSAs.
##PP2
we can still signal UPA for prefix advertised in legacy LSAs,
if we signal U/UP flag in extended LSAs - e.g. sparse mode.
KT2> My understanding of sparse mode is that the extended LSAs
are used for new functionality while the base LSAs are still used
for the base OSPFv3 routing. This allows for a deployment of new
features where not all routers need to support the extended LSAs.
I consider UPA as a new functionality and so it would work with
just the extended LSAs.
So your question is whether we need any base LSA or a Locator
LSA in such case. Well, I guess we don't, but I would mandate
them for consistency reasons - we mandate the presence of the
parent TLV with the NU-bit and LSInfinity metric for these
prefixes in section 5.2.2.
KT2> Let's put aside the Locator LSA - it is completely a
different thing. The base LSAs and extended LSAs both have the
metric (for LSInfinity) and the PrefixOptions (for NU-bit) fields
in them. Only the extended LSAs can carry the U/UP flags.
Therefore, I think it is unnecessary to carry double the LSAs
where the UPA could just be advertised using the extended LSAs.
This is different from OSPFv2 where the OSPFv2 Extended Prefix
LSA didn't have the metric and hence the base LSAs were necessary.
##PP3
I have updated the text:
OLD:
UPA in OSPFv3 is supported for Inter-Area-Prefix-LSA [RFC5340
<https://www.rfc-editor.org/info/rfc5340>], AS-External-LSA
[RFC5340 <https://www.rfc-editor.org/info/rfc5340>], NSSA-LSA
[RFC5340 <https://www.rfc-editor.org/info/rfc5340>],
E-Inter-Area-Prefix-LSA [RFC8362
<https://www.rfc-editor.org/info/rfc8362>], E-AS-External-LSA
[RFC8362 <https://www.rfc-editor.org/info/rfc8362>], E-Type-7-LSA
[RFC8362 <https://www.rfc-editor.org/info/rfc8362>], and SRv6
Locator LSA [RFC9513 <https://www.rfc-editor.org/info/rfc9513>].
NEW:
UPA in OSPFv3 is supported for prefix reachability advertised via
OSPFv3 E-Inter-Area-Prefix-LSA [RFC8362], E-AS-External-LSA
[RFC8362], E-Type-7-LSA [RFC8362], and SRv6 Locator LSA [RFC9513].
For prefix reachability advertised via Inter-Area-Prefix-LSA
[RFC5340], AS-External-LSA [RFC5340], NSSA-LSA [RFC5340], UPA is
signaled using their corresponding extended LSAs. This requires
support of the OSPFv3 Extended LSAs in a sparse mode as specified in
section 6.2 of [RFC8362].
thanks,
Peter
Thanks,
Ketan
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Please find below some comments provided in the idnits output of
the v09 of
the document. Please look for <EoRv09> 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.
<minor> Perhaps remove "existing" from the above sentence in view
of sections
3.2 and 4.2?
##PP
Changed to:
"This document specifies protocol mechanisms in IS-IS
and OSPF, together with
the two new flags, to advertise such prefix
reachability loss."
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
<minor> 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]?
##PP
done.
151 This document defines two new flags in IS-IS, OSPF, and
OSPFv3.
152 These flags, together with the existing protocol mechanisms,
provide
<minor> Perhaps remove "existing" here as well for the same reasons
as
previous comment?
##PP
done
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:
<major> Should we also call out that UPA MUST NOT be generated
unless it is covered
by a summary?
##PP
I would prefer not to limit the UPA for the
summarization use case, even though that is the one we
are targeting now. Maybe we can use it for something
else in the future.
KT> Sure, perhaps there may be such a use case in the
future. However, having a check for summary (it can be
optional), can help purge/remove a whole bunch of UPAs when
the summary itself is gone.
##PP
I would prefer not to mention all possible knobs in the
specification. Such a knob is up to the implementation IMHO.
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.
<minor> s/optimisation/consideration ? ... or perhaps "constraint" ?
##PP
replaced with "consideration"
207 It is also RECOMMENDED that implementations limit the number
of UPA
208 advertisements which can be originated at a given time.
<major> 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.
##PP
it's latter, done.
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:
<minor> For clarity, suggest:
[RFC5305] defines the encoding for advertising IPv4 prefixes using
4 octets of
metric information and its Section 4 specifies:
##PP
done
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.
<minor> Should "will continue to flood them" be qualified as "will
continue to
flood them within the level" or something on similar lines?
##PP
flooding is always limited to the area/level, so not
sure we need to say that.
KT> My concern was with "upgrades all nodes in a network" -
network is broader than area/level and the ABRs/ASBR need to
be updated to go across them in multi-area/level/domain
network.
##PP
ok, added "within the area"
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.
<major> 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?
##PP
done
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).
##PP
I'm not a fan of the deployment considerations in the
RFCs, these should be done by the individual vendors
outside of the IETF. IETF's role is to guarantee
interoperability.
KT> I am not insisting on that. However, I will take this
opportunity to make everyone aware of the work happening on
https://datatracker.ietf.org/doc/draft-opsarea-rfc5706bis/
that will be mandating an operational consideration section
(similar to security considerations) for all specifications.
##PP2
wrong move IMHO, but this is not the right place to debate
that :)
thanks,
Peter
Thanks,
Ketan
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.,:
<major> 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.
##PP
sure, done.
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
<nit> s/e.g.,/i.e.,
##PP
done
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].
<minor> I think the intention here is to say that "UPA in OSPFv2 is
supported
for prefix reachability advertised via ..." ?
##PP
done
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.
<major> This is more of a deployment guideline. Please see similar
comment in
section 3.1
##PP
Changed MUST to "need to"
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
<minor> perhaps s/unreachability/UPA ?
##PP
done
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.
<minor> please update reference to RFC9792 and also "OSPFv2 and
OSPFv3
Prefix Attributes sub-TLVs have been ..."
##PP
I guess it should be "Prefix Extended Flags Sub-TLV
<https://www.rfc-editor.org/rfc/rfc9792.html#name-ospfv2-prefix-extended-flag>s"
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].
<minor> The name is "OSPFv2 Prefix Attributes Sub-TLV"
##PP
shoudl be "OSPFv2 Prefix Extended Flags Sub-TLV
<https://www.rfc-editor.org/rfc/rfc9792.html#name-ospfv2-prefix-extended-flag>"
I suppose.
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.
<major> For OSPFv3, RFC9502 is clear about what metric is in
operation. Is
this text on default and IP algo needed?
##PP
I feel having it here may be useful for people
implementing it.
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
<nit> could be either dropped or delivered ...
##PP
done
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.
<minor> 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.
##PP
I feel like this text is redundant. It was requested by
the earlier review comments, but I feel the meaning of
the U/UP flags is well covered in section 5.
I have removed this text.
496 This document adds two new bits in the "OSPFv2 Prefix Extended
Flags"
497 and "OSPFv3 Prefix Extended Flags" registres:
<nit> registries
##PP
done
thanks,
Peter
<EoRv09>
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
