Hi Robert,
On 23/04/2025 14:57, Robert Raszuk wrote:
Hi Peter,
Say egress PE advertises Max_Metric which does not really cause
unreachability but least preference .. say before maintenance window
happens.
So why wait till the ingress PE really goes down to trigger UPA from
ABRs ?
If the egress PE is the only BGP NH, then reacting to max-metric or
OL-bit set would make some BGP destinations unreachable.
> 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.
See the entire problem is that ingress PE does not have that NH metric
visibility in egress PE area (it is sitting happily in it's own
different area on the other side of the planet) - hence it has no clue
about what is going to happen with egress PE in few moments ...
So why not trigger UPA in such cases to hint him to switch to
alternate next hops if available ?
I'm not saying it can not be done. The implementation can chose to
advertise the UPA for the summary component prefix if the such prefix
metric in the source area/domain crosses certain value or if the prefix
originator is overloaded.
thanks,
Peter
Thx,
R.
On Wed, Apr 23, 2025 at 2:50 PM Peter Psenak <[email protected]> wrote:
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]
