Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

["Acee Lindem (acee)" <[e-mail]>]

From: Robert Raszuk <[e-mail]>
Date: Wednesday, October 13, 2021 at 1:16 PM
To: Acee Lindem <[e-mail]>
Cc: "Peter Psenak (ppsenak)" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"


> How many other PEs does a BGP edge PE maximally peer with?

Typically on IBGP side you will see 2-4 peers. Those are RRs.

Due to no autodiscovery of BGP sessions no many people do iBGP full mesh between PEs.

Then in this case, how many PE next-hops in an IBGP domain? I guess the RR scenario is where we are BFD limited…

Thanks,
Acee



Best,
R.

On Wed, Oct 13, 2021 at 6:48 PM Acee Lindem (acee) <acee=[e-mail]<mailto:[e-mail]>> wrote:
Hi Peter,

See inline.

On 10/13/21, 4:42 AM, "Peter Psenak" <ppsenak=[e-mail]<mailto:[e-mail]>> wrote:

    Hi Acee,

    On 12/10/2021 21:05, Acee Lindem (acee) wrote:
    > Speaking as WG Chairs:
    >
    > The authors of “Prefix Unreachable Announcement” have requested an
    > adoption. The crux of the draft is to signal unreachability of a prefix
    > across OSPF or IS-IS areas when area summarization is employed and
    > prefix is summarised. We also have “IS-IS and OSPF Extension for Event
    > Notification” which can be used to address the same use case. The drafts
    > take radically different approaches to the problem and the authors of
    > both drafts do not wish to converge on the other draft’s method so it is
    > understandable that merging the drafts really isn’t an option.

    just for the record, I offered authors of "Prefix Unreachable
    Announcement" co-authorship on "Event notification" draft, arguing the
    the event base solution addresses their use case in a more elegant and
    scalable way. They decided to push their idea regardless.

One solution to this problem would have definitely been better.

    > Before an adoption call for either draft, I’d like to ask the WG:
    >
    >  1. Is this a problem that needs to be solved in the IGPs? The use case
    >     offered in both drafts is signaling unreachability of a BGP peer.
    >     Could this better solved with a different mechanism  (e.g., BFD)
    >     rather than flooding this negative reachability information across
    >     the entire IGP domain?

    we have looked at the various options. None of the existing ones would
    fit the large scale deployment with summarization in place. Using BFD
    end to end to track reachability between PEs simply does not scale.

It seems to me that scaling of BFD should be "roughly" proportional to BGP session scaling but I seem to be in the minority. My opinion is based on SDWAN tunnel scaling, where BFD is used implicitly in our solution. How many other PEs does a BGP edge PE maximally peer with?
Thanks,
Acee


    Some people believe this should be solved by BGP, but it is important to
    realize that while the problem statement at the moment is primarily
    targeted for egress PE reachability loss detection for BGP, the
    mechanism proposed is generic enough and can be used to track the peer
    reachablity loss for other cases (e.g GRE endpoint, etc) that do not
    involve BGP.

    We went even further and explored the option to use completely out of
    band mechanism that do not involve any existing protocols.

    Simply, the advantage of using IGP is that it follows the existing MPLS
    model, where the endpoint reachability is provided by IGPs. Operators
    are familiar with IGPs and know how to operate them.

    On top of the above, IGP event notification can find other use cases in
    the future, the mechanism defined in draft is generic enough.


    >  2. Assuming we do want to take on negative advertisement in the IGP,
    >     what are the technical merits and/or detriments of the two approaches?

    we have listed some requirements at:

    https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-event-notification-00#section-3

     From my perspective the solution should be optimal in terms of amount
    of data and state that needs to be maintained, ideally separated from
    the traditional LS data. I also believe that having a generic mechanism
    to distribute events has it own merits.

    thanks,
    Peter

    >
    > We’ll reserve any further discussion to “WG member” comments on the two
    > approaches.
    >
    > Thanks,
    > Acee and Chris
    >


_______________________________________________
Lsr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lsr