IETF Last Call Review of draft-ietf-lsr-igp-ureach-prefix-announce-06
review-ietf-lsr-igp-ureach-prefix-announce-05-rtgdir-lc-decraene-2025-05-19-01

Thank you Peter.

-06 address all my comments.

--Bruno

From: Peter Psenak <ppsenak@cisco.com>
Sent: Thursday, May 22, 2025 2:51 PM
To: DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com>
Cc: draft-ietf-lsr-igp-ureach-prefix-announce.all@ietf.org; last-call@ietf.org;
lsr@ietf.org; rtg-dir@ietf.org Subject: Re:
draft-ietf-lsr-igp-ureach-prefix-announce-05 ietf last call Rtgdir review

Hi Bruno,

please see inline (##PP3):

On 21/05/2025 17:18,
bruno.decraene@orange.com<mailto:bruno.decraene@orange.com> wrote: Hi Peter,

Please see inline ##Bruno2

From: Peter Psenak <ppsenak@cisco.com><mailto:ppsenak@cisco.com>
Sent: Tuesday, May 20, 2025 6:53 PM
To: DECRAENE Bruno INNOV/NET
<bruno.decraene@orange.com><mailto:bruno.decraene@orange.com> Cc:
draft-ietf-lsr-igp-ureach-prefix-announce.all@ietf.org<mailto:draft-ietf-lsr-igp-ureach-prefix-announce.all@ietf.org>;
last-call@ietf.org<mailto:last-call@ietf.org>;
lsr@ietf.org<mailto:lsr@ietf.org>; rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>
Subject: Re: draft-ietf-lsr-igp-ureach-prefix-announce-05 ietf last call Rtgdir
review

Hi Bruno,

please see inline (##PP2):

On 20/05/2025 18:02,
bruno.decraene@orange.com<mailto:bruno.decraene@orange.com> wrote: Hi Peter,

Thanks for your reply.
Please see inline ##Bruno

From: Peter Psenak <ppsenak@cisco.com><mailto:ppsenak@cisco.com>
Sent: Tuesday, May 20, 2025 2:22 PM
To: DECRAENE Bruno INNOV/NET
<bruno.decraene@orange.com><mailto:bruno.decraene@orange.com>;
rtg-dir@ietf.org<mailto:rtg-dir@ietf.org> Cc:
draft-ietf-lsr-igp-ureach-prefix-announce.all@ietf.org<mailto:draft-ietf-lsr-igp-ureach-prefix-announce.all@ietf.org>;
last-call@ietf.org<mailto:last-call@ietf.org>;
lsr@ietf.org<mailto:lsr@ietf.org> Subject: Re:
draft-ietf-lsr-igp-ureach-prefix-announce-05 ietf last call Rtgdir review

Hi Bruno,

thanks for your review, please see inline (##PP):

On 19/05/2025 16:54, Bruno Decraene via Datatracker wrote:

Document: draft-ietf-lsr-igp-ureach-prefix-announce

Title: IGP Unreachable Prefix Announcement

Reviewer: Bruno Decraene

Review result: Has Nits

Hello

I have been selected to do a routing directorate "early" review of this draft.

https://www.ietf.org/archive/id/draft-ietf-lsr-igp-ureach-prefix-announce-05.html

The routing directorate will, on request from the working group chair, perform

an "early" review of a draft before it is submitted for publication to the

IESG. The early review can be performed at any time during the draft's lifetime

as a working group document. The purpose of the early review depends on the

stage that the document has reached.

As this document is in working group last call, my focus for the review was to

determine whether the document is ready to be published. Please consider my

comments along with the other working group last call comments.

For more information about the Routing Directorate, please see

https://wiki.ietf.org/en/group/rtg/RtgDir

Document: draft-ietf-lsr-igp-ureach-prefix-announce-05

Reviewer: Bruno Decraene

Review Date: 2025-05-19

Intended Status: Standards Track

Summary:

    I have some minor concerns about this document that I think should be

    resolved before it is submitted to the IESG.

Comments:

== IS-IS UPA ==

It's not crystal clear to me what the normative UPA signal is for IS-IS.

On one hand, section 2.1 seems to say that the UPA signal is a specific (set

of) metric value(s) higher than 0xFE000000, to be chosen locally hence

configured by the network operator. "any prefix advertisement with a metric

value greater than 0xFE000000 can be used for purposes other than normal

routing calculations. Such an advertisement can be interpreted by the receiver

as a UPA." "Optionally, an implementation may use local configuration to limit

the set of metric values which will be interpreted as UPA."

On the other hand, section 5.3 specify that this is the setting of the flags

which signals that the prefix is unreachable

As this is required for interop, this should be clarified. (as per WG

discussion, I believe that §5.3 is right and hence §2.1 needs to be updated)

##PP

In the Introduction section we have a text that says:

"This document defines two new flags in IS-IS and OSPF. These flags, together
with the existing protocol mechanisms, provide the support for the necessary
functionality. The functionality being described is called Unreachable Prefix
Announcement (UPA)."

Section 2.1 talks specifically about the metric used with the UPA. It does not
conflict with the section 5.3.

What about if I modify the text in section 2.1 as follows:

"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. The usage of such metric MUST
be used when advertising the UPA."

And I will remove the following text:

"Optionally, an implementation may use local configuration to limit the set of
metric values which will be interpreted as UPA. The only restriction is that
such values MUST be greater than 0xFE000000."

##Bruno Looks good. Thank you.

== OSPF UPA ==

§3.1 I'm not familiar with OSPF, but the 2 following sentences seems

inconsistent: "Existing nodes in a network which receive UPA advertisements

will propagate it following existing standard procedures defined by OSPF."

"OSPF Area Border Routers (ABRs), which would be responsible for propagating

UPA advertisements into other areas would need to recognize such

advertisements."

I'm reading the first sentence as saying existing (all) nodes will propagate

UPA as per pre-existing OSPF standard procedures. While the second sentence

seems to say that ABR would need to be upgrated or configured to recognize UPA.

Also, those two sentences seem to be related to §3.2 "Propagation of UPA in

OSPF" so may be they should be moved to §3.2.

##PP

What about this:

3.1 Advertisement of UPA in OSPF

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 the UPA.

"UPA flooding inside the area follows the existing existing standard procedures
defined by OSPF."

3.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.

Advertising prefix reachability between OSPF areas assumes prefix reachability
in a source area. Such requirement of reachability MUST NOT be applied for
UPAs, as they are propagating unreachability.

OSPF ABRs may wish to advertise received UPAs into other connected areas. When
doing so, the original LSInfinity metric value in UPA MUST be preserved. The
cost to reach the originator of the received UPA MUST NOT be considered when
readvertising the UPA to connected areas.

##Bruno Looks good. Thank you.

== UPA ==

§5.1 and §5.2.1/2 includes the specification on the receiver, in particular

"error handling" when the flag does not match the metric. It would be good to

also specify the error handling when the node advertising the UPA does not

advertise a summary address. (this is mandatory as per §4)

##PP

I' would not limit the UPA usage to summarization. Maybe we find other use case
in the future.

Section 4 says MAY, it does not say UPA MUST NOT be generated otherwise.

##Bruno OK

== deployment consideration ==

The first four paragraph of §6 seems to be part of the specification (for

implementors) rather than part of "deployment consideration" (mostly for

network operators) I think they should be moved to a different section.

##PP
I'm not sure I feel the same, but if you insist, I can move them to a new
section that you provide a name for :)

##Bruno
I would move them in § 4. "Generation of the UPA". But I'm not insisting, up to
you.

== §6 ==

" UPA advertisements SHOULD therefore be withdrawn after a modest amount of

time" It's not clear to me why this time requirement ("modest amount of time")

is added. This seems to double the amount of churn, while the UPA withdraw

could possibly be delayed up to the next LSA/LSP refreshment. (the drawback

seems some extra memory usage in routers, but few octets for a few hours are

expected to be OK in such scalled networks requiring multiple areas and

aggregation)

##PP

UPA is by nature ephemeral, so it makes no sense to keep it in the network when
it provides no useful state.

##Bruno
State is ephemeral. But this delay may be enforced locally without requiring
signaling.

##PP2

how? The UPA TLV is a regular prefix TLV that can only be removed by its
originator.

##Bruno2 Sure, TLV would stay. But thanks to the metric, it will not be used
for normal routing calculations. Then "usage of them is outside of scope of
this document". And the usage could be defined to not use the UPA after a
certain duration.

##PP3
what you are proposing is to add a timestamp to the TLV and use the TLV based
on its lifetime. I don't think we want to make such a change to the protocol
operation. Pulse draft attempt that at the LSP level and it was considered too
radical change to the protocol. Doing it at TLV level is even more radical...

Cf draft-ppsenak-lsr-igp-event-notification "Limited Lifetime - pulses are
short-lived.  There is no flushing or purging mechanism for pulses. »

##PP2

right, but there we defined a new LSP that had the ephemeral nature, we don't
have it in the base protocol.

My question is about the cost & benefit of _signaling_ the UPA withdraw.
And its urgency. The document recommends a second signaling within the
timeframe of the failure. However, the failure may be more extensive and may
require more signaling from other nodes. Adding signaling for very added value
within this failure timeframe is adding stress at the wrong time.

##PP2

UPA usefulness ends once it is fully flooded. There is no point to keeping it
around for a long time.

I think the document is very good in stating that a minimal delay should be
used, to make sure that the LSP had time to be flooded. (which may be a
question in itself given the discussion on
draft-rigatoni-lsr-isis-fragment-timestamping. i.e., how long does it take to
flood LSP in large deployment). But to me the maximum delay could be left to
each implementation, possibly depending on the conditions at the time (the
scale, instability in the network, number of UPA to be withdrawn...).

##PP2

We are not specifying any specific time, we are leaving it up to the
implementation. The existing text tries to explain the fact that there is no
point keeping the UPA for a long period of time. I can change "SHOULD therefore
be withdrawn after a modest amount of time" with "SHOULD not be kept for a
prolonged period of time" if that makes you fell better about it.

##Bruno2 Works for me, thanks (alternatively, :s/modest amount of/some).

I also like "The time the UPA is kept in the network SHOULD also reflect the
intended use-case for which the UPA was advertised." But this adds an
unnecessary dependency as the ABR would need to be aware of the application
using the UPA. One option would be for this delay to be configuration by the
network operator, but this may be a bit late to introduce this, even if a MAY
makes it purely optional.

##PP3
I will add that to the draft.

Another option may be to specify a minimum amount of time such that application
can decide whether this is enough for them, or not. May be also adding an
example with BGP PIC as "a modest amount of time" may means something different
for an IGP guy and for a BGP guy. For example "For BGP PIC Edge, this means
enough time for the BGP convergence to be finished."

##PP3
I would rather avoid getting into the specifics of the particular use
case/application. We want to keep the UPA mechanism generic enough.

Finally, I would prefer to see a text requiring the withdraw of the UPA if the
prefix comes back up. I don't remember reading this point in the current text.
##PP3

that is assumed to be the case, but I can add a text.

thanks,
Peter

Anyway, up to you. Feel free to upload a new version at your convenience.

Thanks,

--Bruno

thanks,
Peter

Thanks,

--Bruno

--

The IANA section requests IANA to allocate new flags, while the IANA has

already allocated them. I would suggest to update the text with the allocated

values, and to ask IANA to make these allocations permanent. (An example of

sentence may be found in first paragraph of

https://datatracker.ietf.org/doc/html/draft-ietf-idr-entropy-label-17#name-iana-considerations)

Other sections in the document have "Bit TBD" and needs to be updated to

reflect the IANA allocations.

##PP

sure, will update that once we agree on the above changes. We now have the IANA
allocations for OSPFv2/v3

thanks,
Peter

===

Typo:

§1 :s/OSPFV3/OSPFv3

§2.2 :s/vice verse/vice versa

§4 :s/ISIS/IS-IS

§8.2 :s/registres/registries

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.

Thank you.

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.

Thank you.

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites
ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez
le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration, Orange decline toute
responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law; they should not be distributed, used
or copied without authorisation. If you have received this email in error,
please notify the sender and delete this message and its attachments. As emails
may be altered, Orange is not liable for messages that have been modified,
changed or falsified. Thank you.