Robert, I didn't see anything in the document that restricts the UPA to a
/32 or a /128. However, you will find the text below in
https://www.ietf.org/archive/id/draft-ietf-lsr-igp-ureach-prefix-announce-09.html#section-2
that may be somewhat related to what you are looking for ?

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.

Thanks,
Ketan


On Wed, Sep 24, 2025 at 4:07 AM Robert Raszuk <[email protected]> wrote:

> All,
>
> Reading the below I have a tiny question -
>
> Can UPA be a (sub)summary route covering in one shot more than one address
> which went down ? Or is there any mandate in the draft that UPA MUST ALWAYS
> be /32 or /128 only ?
>
> Apologies if I missed an answer to it in the text of the draft.
>
> Thx,
> R.
>
>
>
>> 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.
>>
>
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to