ok, but then I'm confused about all those requirements about retainting IDs & SeqNr# and so on ... they are pretty meaningless unless you want to pulse within 60 secs negative again (why would you?)
and it brings up the issue of having anycast for e.g. load-balancing or reliability and one pulse basically tearing the session for another destination. --- tony On Wed, Dec 1, 2021 at 3:42 PM Robert Raszuk <rob...@raszuk.net> wrote: > Hi Tony, > > > Do we assume the negative just quickly tears down the BGP session & then > it loses any relevance > > and we rely on BGP to retry after reset automatically or something? > > That is my understanding that PULSE is one time send and forget. The > entire operation relies on upper layers for it to be operationally > meaningful. > > It kind of works if there are upper layers (BGP or p2p tunnel) It does not > work where there is just p2mp tunnel with no upper layer. > > But your note brings an important question which was not discussed - what > if the summary is conditional based on the presence of specific host routes > and those host routes went down. I guess the draft should mandate that the > summary must be just static to null int. > > Thx, > R. > > On Wed, Dec 1, 2021 at 3:32 PM Tony Przygienda <tonysi...@gmail.com> > wrote: > >> having thought through that a bit more I think it's a significantly worse >> idea than I actually thought. You are requesting a node to basically save a >> possibly very large amount of state between reboots in transitive fashion >> for this to even have a chance to work half-way reliably (assuming >> signalling "down" means "it went down and stays down" which surely has to >> include "positive pulses" as well BTW AFAIS?) >> >> Imagine following scenario: >> >> router L1 A summarizes 10.1/16 and realizes a 10.1.1.1 behind it went >> down (the reason may not be in ISIS, e.g. redistributed 10.1.1.1 was one of >> the triggers for 10.1/16 and now is not redistributed anymore). it pulses >> negative and has to retain >> >> * A pulsed negative under a 10.1/16 for 10.1.1.1 (and what was the >> "origiin" of 10.1.1.1 that was lost to pulse it) >> * A pulsed in some ID @ some seqnr# and possibly more stuff >> >> it hits on the border a L1/L2 router B sumarizing 10/8 which now >> re'pulses into L2 (or leaks it up, it's same thing, you have to keep state >> since the LSP will "expire" within short period) >> >> * keep seqnr# of the "re"-pulsed negative, which pulse from whom >> triggered it (there may be multiple folks etc) >> * keep ID of the "re"-pulsed negative >> >> I don't think you get away from doing that since A is not visible in L2 >> and if there is a A' with 10.1.1.1/32 in the same L1 B MUST suppress A's >> pulse otherwise the other end of network cannot tell whether "all" o9r just >> "some" of 10.1.1.1 in the area went away. >> >> So in a sense the state in B will be "stuck" if A reboots (unless you >> start to generate lots of rules about re-computing reachability to A and >> based on that remove that state to make sure the L2 "re"-pulse is >> withdrawn. or should it? A link failure here can cause quickly a good >> amount of "positive pulse" storms for all the negative pulse state kept @ >> the border. A going away is kind of confirmation that the negative is still >> negative or does it invalidate the pulse of A. If it doesn't and A goes >> down the negative is stuck forever and B will repulse it after reboot? is >> here a transitive algebra of some kind?) >> >> Some goes for a C @ another L2/L1 border trying to "leak it down" of >> course >> >> now comes a more interesting part. >> >> A is shut down, its configuration changed to not include 10.1/16 anymore >> (but possibly something subsuming/supersuming). On reboot one has to build >> a whole logic computing all the retained negative so they can be pulsed >> "positive" to remove the state from B (unless B pulese positive the moment >> A goes away which kinds of seems to defaeat the purpose of the whole >> negative and is opposite to what one does if A advertises 10.1.1.1/32 >> directly which going away kind of should pulse it negative from B) >> >> And I won't even ask what happens if A reboots with a different router >> ID. Well, maybe? do you start to pulse with old router-ID since otherwise B >> will not remove the retained state? That seems like a prescription for >> spectacular meltdowns a la proxy purging that had to be removed. >> >> Just bunch thoughts to improve the draft @ best but most likely showing >> futility of that approach IMO to construct a clean algebra/architecture of >> that stuff under summarization on a global leak-up-down-scope. >> >> Or maybe I missed something in the draft or between the lines in the >> whole thing ... Do we assume the negative just quickly tears down the BGP >> session & then it loses any relevance and we rely on BGP to retry after >> reset automatically or something? But then why do we even care about >> retaining the LSP IDs & SeqNr# would I ask? >> >> -- tony >> >> >> >> >> >> On Tue, Nov 30, 2021 at 11:19 PM Les Ginsberg (ginsberg) <ginsberg= >> 40cisco....@dmarc.ietf.org> wrote: >> >>> Hannes - >>> >>> Please see >>> https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-event-notification-00#section-4.1 >>> >>> The new Pulse LSPs don't have remaining lifetime - quite intentionally. >>> They are only retained long enough to support flooding. >>> >>> But, you remind me that we need to specify how the checksum is >>> calculated. Will do that in the next revision. >>> >>> Thanx. >>> >>> Les >>> >>> > -----Original Message----- >>> > From: Hannes Gredler <han...@gredler.at> >>> > Sent: Tuesday, November 30, 2021 11:22 AM >>> > To: Peter Psenak (ppsenak) <ppse...@cisco.com> >>> > Cc: Robert Raszuk <rob...@raszuk.net>; Les Ginsberg (ginsberg) >>> > <ginsb...@cisco.com>; Aijun Wang <wangai...@tsinghua.org.cn>; lsr >>> > <lsr@ietf.org>; Tony Li <tony...@tony.li>; Shraddha Hegde >>> > <shrad...@juniper.net> >>> > Subject: Re: [Lsr] BGP vs PUA/PULSE >>> > >>> > hi peter, >>> > >>> > Just curious: Do you have an idea how to make short-lived LSPs >>> compatible >>> > with the problem stated in >>> > https://datatracker.ietf.org/doc/html/rfc7987 >>> > >>> > Would like to hear your thoughts on that. >>> > >>> > thanks, >>> > >>> > /hannes >>> > >>> > On Tue, Nov 30, 2021 at 01:15:04PM +0100, Peter Psenak wrote: >>> > | Hi Robert, >>> > | >>> > | On 30/11/2021 12:40, Robert Raszuk wrote: >>> > | > Hey Peter, >>> > | > >>> > | > > #1 - I am not ok with the ephemeral nature of the >>> advertisements. (I >>> > | > > proposed an alternative). >>> > | > >>> > | > LSPs have their age today. One can generate LSP with the >>> lifetime of 1 >>> > | > min. Protocol already allows that. >>> > | > >>> > | > >>> > | > That's a pretty clever comparison indeed. I had a feeling it will >>> come >>> > | > up here and here you go :) >>> > | > >>> > | > But I am afraid this is not comparing apple to apples. >>> > | > >>> > | > In LSPs or LSA flooding you have a bunch of mechanisms to make >>> sure the >>> > | > information stays fresh >>> > | > and does not time out. And the default refresh in ISIS if I recall >>> was >>> > | > something like 15 minutes ? >>> > | >>> > | yes, default refresh is 900 for the default lifetime of 1200 sec. >>> Most >>> > | people change both to much larger values. >>> > | >>> > | If I send the LSP with the lifetime of 1 min, there will never be any >>> > | refresh of it. It will last 1 min and then will be purged and >>> removed from >>> > | the database. The only difference with the Pulse LSP is that it is >>> not >>> > | purged to avoid additional flooding. >>> > | >>> > | >>> > | > >>> > | > Today in all MPLS networks host routes from all areas are >>> "spread" >>> > | > everywhere including all P and PE routers, that's how LS >>> protocols >>> > | > distribute data, we have no other way to do that in LS IGPs. >>> > | > >>> > | > >>> > | > Can't you run OSPF over GRE ? For ISIS Henk had proposal not so >>> long ago >>> > | > to run it over TCP too. >>> > | > >>> https://datatracker.ietf.org/doc/html/draft-hsmit-lsr-isis-flooding-over- >>> > tcp-00 >>> > | >>> > | you can run anything over GRE, including IGPs, and you don't need TCP >>> > | transport for that. I don't see the relevance here. Are you >>> suggesting to >>> > | create GRE tunnels to all PEs that need the pulses? Nah, that would >>> be an >>> > | ugly requirement. >>> > | >>> > | thanks, >>> > | Peter >>> > | >>> > | >>> > | > >>> > | > Seems like a perfect fit ! >>> > | > >>> > | > Thx, >>> > | > R. >>> > | >>> >>> _______________________________________________ >>> 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
