Hi Robert,
sorry, I misunderstood your original question.
If the OL bit, or max-metric does not result in prefix becoming
unreachable on the ABR/ASBR that originates the summary covering the
prefix, there is no need to generate UPA. The prefix is still reachable
and if the BGP selection on the ingress PE uses the IGP metric towards
the NH as one of the rules for selecting the best path, the traffic will
be rerouted to the alternate PE.
thanks,
Peter
On 23/04/2025 13:41, Robert Raszuk wrote:
I would just suggest to make it explicit in this bullet:
Instead:
*/ - reachability of a prefix that was reachable earlier was lost/*
*/
/*
*/say: /*
*/
/*
*/ - reachability of a prefix that was reachable earlier was lost or
node originating such prefix was signalled with OL bit set or
MAX_METRIC set./*
or something along those lines.
Thx,
R.
On Wed, Apr 23, 2025 at 12:16 PM Peter Psenak <[email protected]> wrote:
Hi Robert,
On 23/04/2025 11:49, Robert Raszuk wrote:
HI Peter,
Cool. So can you a bit reword this section 4 to make it clear ?
and what exactly is not clear and how would you suggest to reword it?
thanks,
Peter
Thx,
R.
On Wed, Apr 23, 2025 at 8:52 AM Peter Psenak <[email protected]>
wrote:
Robert,
On 23/04/2025 00:44, Robert Raszuk wrote:
All,
I have one more question in respect to the text in the draft
...
*/4. Generation of the UPA
UPA MAY be generated by the ABR or ASBR that is
performing the
summarization, when all of the following conditions are met:
- reachability of a prefix that was reachable earlier
was lost
- a summary address which covers the prefix is being
advertised by
the ABR/ASBR/*
So with the above text in mind would we advertise UPA when:
A) Operator manually sets overload bit on an egress PE ?
(Technically the node is still reachable)
B) Operator manually forces to advertise within L1 max
metric for its router-LSA ? (Technically the node is still
reachable)
In both cases the second condition is met - summary covers
the egress node of the sare L1 or non 0 area.
My reading of section 4 leads me to believe that the answer
to both (A) and (B) questions is "no" - and that would be
perhaps something worth revisiting.
yes, UPA would be advertised. The point is that you want the
ingress PE to reroute if there is an alternative egress PE
that can reach BGP prefix located behind the PE where (A) or
(B) was done.
thanks,
Peter
Thx,
Robert
On Tue, Apr 22, 2025 at 11:29 PM Robert Raszuk
<[email protected]> wrote:
Hi Les,
Let's open a bit of imagination and assume one day we
progress
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-extended-hierarchy-06
Do you think this is wise to blast UPAs everywhere in
all 8 levels when perhaps it is needed only on a
few egress nodes sitting in one specific area of say
level 4 ?
I do understand your statement that since we are
creating summaries we are the problem and need to fix it
but let's not forget that summaries are created by
operators and such operators can use other tools to
signal holes in them. Both droid and bgp based models
have been discussed yet UPA is being pushed.
It seems that UPAs are example of very good marketing
skills :).
Cheers,
Robert
On Tue, Apr 22, 2025 at 4:35 PM Les Ginsberg (ginsberg)
<[email protected]> wrote:
I support progression of the UPA draft.
It leverages an existing mechanism in the protocols
to provide needed functionality - which has been
proven viable by multiple implementations.
As I have commented in the past, I do wish the
definition of the flags was modified so they were
not mutually exclusive. This model leads to the
inability to add additional related flags in the
future without creating a backwards compatibility issue.
Regarding concerns expressed by other WG members as
to the appropriateness and scalability of the
mechanism defined here:
I think the draft is careful in defining how the
mechanism should be used so
as to avoid scalability issues. I also think no one
has offered an alternative which is more scalable.
Given IGPs already advertise reachability,
summaries, and unreachability, this mechanism is
clearly an appropriate use of the IGPs.
Les
*From:*Yingzhen Qu <[email protected]>
*Sent:* Thursday, April 17, 2025 11:13 AM
*To:* lsr <[email protected]>; lsr-chairs
<[email protected]>
*Subject:* [Lsr] WG Last Call for
draft-ietf-lsr-igp-ureach-prefix-announce (4/17/2025
- 5/2/2025)
Hi,
This email begins a 2 week WG Last Call for the
following draft:
IGP Unreachable Prefix Announcement
https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-ureach-prefix-announce/
Please review the document and indicate your support
or objections by May 2nd, 2025.
Authors and contributors,
Please indicate to the list your knowledge of any
IPR related to this work.
Thanks,
Yingzhen
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
