Hi Bruno,
please see inline (##PP3):
On 21/05/2025 17:18, [email protected] wrote:
Hi Peter,
Please see inline ##Bruno2
*From:*Peter Psenak <[email protected]>
*Sent:* Tuesday, May 20, 2025 6:53 PM
*To:* DECRAENE Bruno INNOV/NET <[email protected]>
*Cc:* [email protected];
[email protected]; [email protected]; [email protected]
*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, [email protected] wrote:
Hi Peter,
Thanks for your reply.
Please see inline ##Bruno
*From:*Peter Psenak <[email protected]> <mailto:[email protected]>
*Sent:* Tuesday, May 20, 2025 2:22 PM
*To:* DECRAENE Bruno INNOV/NET <[email protected]>
<mailto:[email protected]>; [email protected]
*Cc:* [email protected];
[email protected]; [email protected]
*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.
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
