Robert,

On 27/03/2023 17:18, Robert Raszuk wrote:
> All it does that it advertises UPA for  prefixes that are summarized on it and change from reachable to unreachable

Ok but this is a bit too vague,

If my ABR disconnects from an area nodes it should remove the summary and not inject possibly 100s or 1000s of UPAs. And IMO the draft should describe this procedure in detail.

Section 6 has the following text:

"It is also recommended that implementations limit the number of UPA
 advertisements which can be originated at a given time."

thanks,
Peter

Thx,
R

On Mon, Mar 27, 2023 at 8:07 AM Peter Psenak <[email protected] <mailto:[email protected]>> wrote:

    Robert,

    On 27/03/2023 16:57, Robert Raszuk wrote:
     >     Hi Peter,
     >
     >      >  4. Is an UPA for a /24 equivalent to 255 UPA for /32?
    (i.e. will
     >      >     trigger BGP PIC edge for 255 /32)
     >
     >     no. For BGP PIC to be triggered by UPA, the UPA must be sent
    for the
     >     prefix that is used to resolve BGP prefixes. But the
    treatment of the
     >     UPA is outside of the scope.
     >
     >
     > "UPA must be sent for the prefix that is used to resolve BGP
    prefixes."
     >
     > Are you saying that UPA is only /32 or /128 ?

    I have not said that.


     >
     > So if my PE has /64 loopback and I use it for next hops I can not
    send
     > UPA for /64 ?

    sure you can.

     > And how would ABR know what I am using as BGP next hops if
     > it may not even run service BGP at all ?

    it does not need to know. All it does that it advertises UPA for
    prefixes that are summarized on it and change from reachable to
    unreachable. If you use /32 as BGP HN and it is covered by the summary,
    when you receive UPA for that /32 you may decide to activate PIC. Same
    is true if you resolve over /64 locator instead of /32. Again, all this
    is up to the implementation. All that drafts specifies is the
    indication
    of the unreachability from the summarization point.

    Peter

     >
     > Thx.
     > R.
     >
     >


_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to