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 <rob...@raszuk.net> 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)
    <ginsberg=40cisco....@dmarc.ietf.org> 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 <yingzhen.i...@gmail.com>
        *Sent:* Thursday, April 17, 2025 11:13 AM
        *To:* lsr <lsr@ietf.org>; lsr-chairs <lsr-cha...@ietf.org>
        *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 -- lsr@ietf.org
        To unsubscribe send an email to lsr-le...@ietf.org

_______________________________________________
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org

Reply via email to