Greg,
On 13/10/2021 22:45, Greg Mirsky wrote:
Hi Les, et al.,
I've just read the draft-ppsenak-lsr-igp-event-notification. Event
notification is usually viewed as the function of the Fault Management
OAM, not of a control plane protocol. Thus, I find the idea of using an
IGP protocol to distribute event notifications troubling. One of my
concerns is with the ability to control the scope of who receives the
notification. Even though the proposal follows RFC 7356, it might still
be too broad. In my experience, usually only designated systems in a
domain are to receive a notification about the particular class of
events. In fact, a publish-subscribe model for event notification is
seen as more suitable than flooding. AFAIK, there are different
solutions for publish-subscribe event notifications using gRPC, Kafka, etc.
sure, we have even tried something like that. We soon realized that to
distribute the "publish-subscribe event notifications" between all PEs
in a scalable, reliable and fast way you would need a some sort of
distribution infra as doing full mesh is not going to work. And once you
get to build that distribution infra you will end up defining a new
protocol.
So while I appreciate your concern, we are not attempting to advertise
any type of events in the IGPs. We limit it to the events related to the
routing and path computation, which is what IGPs are used for.
thanks,
Peter
Regards,
Greg
On Wed, Oct 13, 2021 at 11:44 AM Les Ginsberg (ginsberg)
<[email protected]
<mailto:[email protected]>> wrote:
This thread is becoming "diverse".
We are trying to talk about many different solutions (IGP, BGP, BFD)
- all of which may be useful and certainly are not mutually exclusive.
If we can agree that an IGP solution is useful, then we can use this
thread to set a direction for the IGP solution - which seems to me
to be something we should do independent of whether the other
solutions are also pursued.
With that in mind, here is my input on the IGP solutions:
PUA
-------
For me, the solution has two major drawbacks:
1)It tries to repurpose an existing (and fundamental) Reachability
Advertisement into an UnReachability advertisement under certain
conditions
The interoperability risks associated with this make me very
reluctant to go down this path.
And the use of the same advertisement to indicate Reachability and
Unreachability is IMO highly undesirable.
2)The withdrawal of the "Unreachability Advertisement" after some
delay (which is necessary) remains problematic despite the authors
attempts to address thus
Event Notification
------------------------
This avoids the drawbacks of PUA and is flexible enough to handle
future and unforeseen types of notifications.
I would like to extend the offer already made by Peter to the
authors of PUA to join us and work on the Event Notification draft.
The authors of PUA certainly deserve credit for raising awareness of
the problem space and it would be good to have them working with us
on a single IGP solution.
But PUA is not an alternative that I can support.
Les
> -----Original Message-----
> From: Lsr <[email protected] <mailto:[email protected]>> On
Behalf Of Acee Lindem (acee)
> Sent: Wednesday, October 13, 2021 9:49 AM
> To: Peter Psenak <[email protected]
<mailto:[email protected]>>; [email protected] <mailto:[email protected]>
> Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS
and OSPF
> Extension for Event Notification"
>
> Hi Peter,
>
> See inline.
>
> On 10/13/21, 4:42 AM, "Peter Psenak"
> <[email protected]
<mailto:[email protected]>> 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
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
