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
