Hi Les, Indeed "for the given use case that amount/rate of traffic would be unusual." that is completely right and that is why I said to Peter that I will support this draft if it comes to WG adoption.
But what is the mechanism the gate will stop to only allow light event notification like PE down events to ride on top of this ? As you may know most required and missing feature is to carry external peer's down events when we set next hop self. Today workaround is to set external interfaces as passive and do propagate such transitions in IGP as state for IPv4/v6 routes. For other address families which relay on next-hop-self this is much more difficult and we use BGP for it. I can already envision folks writing a two page draft adding interface ID to BGP PATH_INFO and asking IGP to send such notifications all over as events. Out of the sudden from a very innocent extension we can turn to a monster feature as external interfaces do flap a lot. But anyway - as you and all know I always endorse good innovation ! Cheers, R. On Thu, Oct 14, 2021 at 12:23 AM Les Ginsberg (ginsberg) <ginsb...@cisco.com> wrote: > Robert – > > > > You are (of course) right. But the question is whether it is worth the > effort to define a specific flooding topology for this use case? If the > answer to that is “yes”, then I think a BGP solution would probably make > more sense. > > Alternatively, we could use a separate IGP instance for this use case. > Nothing in the event notification draft precludes that. I do think, > however, that it significantly raises the bar for deployment, and it may > well be more practical to flood the info on the routing topology and let > the nodes who can make use of the info use it and have the rest ignore it. > > > > If this was expected to be a large amount of information and needed to be > sent with great frequency, I think your preference might well make more > sense – but for the given use case that amount/rate of traffic would be > unusual. > > > > Les > > > > > > *From:* Robert Raszuk <rob...@raszuk.net> > *Sent:* Wednesday, October 13, 2021 1:57 PM > *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com> > *Cc:* Acee Lindem (acee) <a...@cisco.com>; Peter Psenak (ppsenak) < > ppse...@cisco.com>; lsr@ietf.org > *Subject:* Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and > OSPF Extension for Event Notification" > > > > Hi Les, > > > > I agree with all you said except this: > > > > *The nodes to whom this information needs to be flooded are the same nodes > which have received the summary address advertisement.* > > > > I really do not think so. Only a subset of nodes which received IGP > summary route may need to know about the failures of nodes covered by such > summary. That's important to agree on. > > > > That includes both P and PE routers. I would argue that in any real > network where some form of encapsulation is used for services no P router > is interested to know in holes summary information in the adjacent domains > (well unless you envision such holes to be converted to ACLs to blindly > drop traffic as early as possible :) > > > > Then in many many networks PEs usually carry subset of services > originating in other PE's hence they careless in holes in any other PEs > they do not have active next hops for. > > > > Cheers, > > R. > > > > > > > > > > > > > > On Wed, Oct 13, 2021 at 10:37 PM Les Ginsberg (ginsberg) < > ginsb...@cisco.com> wrote: > > Robert – > > > > Inline. > > > > *From:* Robert Raszuk <rob...@raszuk.net> > *Sent:* Wednesday, October 13, 2021 12:52 PM > *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com> > *Cc:* Acee Lindem (acee) <a...@cisco.com>; Peter Psenak (ppsenak) < > ppse...@cisco.com>; lsr@ietf.org > *Subject:* Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and > OSPF Extension for Event Notification" > > > > Hi Les, > > > > > If we can agree that an IGP solution is useful, then we can use this > thread to > > > set a direction for the IGP solution > > > > I think this thread aimed to answer both of those questions hence some > comments. > > > > *[LES:] Yes – and all discussion is very relevant. I am suggesting that > maybe it would be more productive to have separate threads/solution.* > > *I am of the opinion that we need an IGP solution – but I believe a BGP > based solution could also prove useful.* > > > > But even if we assume that Event Flooding via IGP have a valid use case > (regardless if PE down is a right one) I am a bit concerned with adding > this new such functionality to existing IGPs. Event flooding with IGPs (the > way I see similar opaque information and how they got into other protocols) > may quickly become a huge burden to them. > > > > Yes I see you are already proposing separation of LSDBs via FSP Scope > Specific LSDB - but is this enough ? > > > > How about redistribution between IGP instances across domains ? > > *[LES:] Redistribution is a local behavior which has never been subject to > standardization.* > > *Certainly, an implementation could choose to support this.* > > > > So assuming we want to do that new event transport how about running new > instance of link state dedicated for event flooding ? It seems (no matter > how we look at it) that there are many differences in operational models > for state advertisement vs events in an IGP. > > > > Moreover such new instance could only be spanning PEs and if we do it > right it can be based on a pub/sub model. > > > > *[LES:] So, you know I am a staunch advocate of restricting what the IGPs > advertise.* > > *In this use case, however, I think use of the “routing instance” is > appropriate.* > > *It is the fact that the IGP is advertising the summary address that makes > the advertisement of the loss of reachability to specific nodes covered by > that summary by the same IGP instance an attractive choice.* > > *The nodes to whom this information needs to be flooded are the same nodes > which have received the summary address advertisement.* > > > > *I can imagine that for other uses cases, event notification might well be > done by a separate instance.* > > *We can certainly add a discussion of the use of a separate instance into > the event notification draft.* > > > > * Les* > > > > > > Thx, > > R. > > > > > > > > > > > > > > On Wed, Oct 13, 2021 at 8:44 PM Les Ginsberg (ginsberg) <ginsberg= > 40cisco....@dmarc.ietf.org> 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 <lsr-boun...@ietf.org> On Behalf Of Acee Lindem (acee) > > Sent: Wednesday, October 13, 2021 9:49 AM > > To: Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org>; lsr@ietf.org > > 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" > > <ppsenak=40cisco....@dmarc.ietf.org> 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 > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
