1. my question is different. why does the draft say that seqnr# & IDs have to be preserved between restarts
2. I'm still concerned about L1/L2 hierarchy. If an L2 border sees same prefix negative pulses from two different L1/L2s it still has to keep state to only pulse into L1 after _all_ the guys pulsed negative (which is basically impossible since the _negative_ cannot persist it seems). Now how will it even know that? it has to keep track who advertised the same summary & who pulsed or otherwise it will pulse on anyone with a summary giving a pulse and with that anycast won't work AFAIS and worse you get into weird situations where you have 2 L1/L2 into same L1 area, one lost link to reach the PE (arguably L1 got partitioned) and pulses & then the L1/L2 on the border of the down L1 pulses and tears the session down albeit the prefix is perfectly reachable through the other L1/L2. I assume that parses for the connoscenti ... -=--- tony On Wed, Dec 1, 2021 at 4:00 PM Peter Psenak <[email protected]> wrote: > Tony, > > On 01/12/2021 15:31, Tony Przygienda wrote: > > > > > 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? > > yes. > > > But then why do we even care about retaining the LSP IDs & SeqNr# would > I ask? > > it's used for the purpose of flooding, so that during the flooding you > do not flood the same pulse LSP multiple times. > > thanks, > Peter > > > > > > -- tony > > > > > > > > > > > > On Tue, Nov 30, 2021 at 11:19 PM Les Ginsberg (ginsberg) > > <[email protected] > > <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected] > >> > > > Sent: Tuesday, November 30, 2021 11:22 AM > > > To: Peter Psenak (ppsenak) <[email protected] > > <mailto:[email protected]>> > > > Cc: Robert Raszuk <[email protected] <mailto:[email protected]>>; > > Les Ginsberg (ginsberg) > > > <[email protected] <mailto:[email protected]>>; Aijun Wang > > <[email protected] <mailto:[email protected]>>; lsr > > > <[email protected] <mailto:[email protected]>>; Tony Li <[email protected] > > <mailto:[email protected]>>; Shraddha Hegde > > > <[email protected] <mailto:[email protected]>> > > > 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 > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/lsr > > > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
