Subject: Re: [Lsr] BGP vs PUA/PULSE

From: Tony Przygienda <[email-masked]>
Date: Wed, 1 Dec 2021 15:31:30 +0100

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=
[email-masked]> 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-masked]>
> > Sent: Tuesday, November 30, 2021 11:22 AM
> > To: Peter Psenak (ppsenak) <[email-masked]>
> > Cc: Robert Raszuk <[email-masked]>; Les Ginsberg (ginsberg)
> > <[email-masked]>; Aijun Wang <[email-masked]>; lsr
> > <[email-masked]>; Tony Li <[email-masked]>; Shraddha Hegde
> > <[email-masked]>
> > 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-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 1 Dec 2021 15:42:00 +0100

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 <[email-masked]> wrote:

> 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
> 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?)
>
>> But, you remind me that we need to specify how the checksum is
>> calculated. Will do that in the next revision.
>>
>> Thanx.
>>
>>     Les
>>
>> > | > Can't you run OSPF over GRE ? For ISIS Henk had proposal not so
>> long ago
>> > | 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
>> > |
>> > |
>> > | >

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 1 Dec 2021 15:54:51 +0100

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 <[email-masked]> wrote:

> 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.
>
>> 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
>> 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)
>> 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
>> 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
>>
>>
>>
>>
>>
>>> > | > In LSPs or LSA flooding you have a bunch of mechanisms to make
>>> sure the
>>> > | refresh of it. It will last 1 min and then will be purged and
>>> removed from

---

From: Peter Psenak <[email-masked]>
Date: Wed, 1 Dec 2021 16:00:23 +0100

Tony,

On 01/12/2021 15:31, Tony Przygienda wrote:

> 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) 
> <ginsberg=[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hannes -
> 
>     Please see
>      > From: Hannes Gredler <[email-masked] <mailto:[email-masked]>>
>      > To: Peter Psenak (ppsenak) <[email-masked]
>     <mailto:[email-masked]>>
>      > Cc: Robert Raszuk <[email-masked] <mailto:[email-masked]>>;
>     Les Ginsberg (ginsberg)
>      > <[email-masked] <mailto:[email-masked]>>; Aijun Wang
>     <[email-masked] <mailto:[email-masked]>>; lsr
>      > <[email-masked] <mailto:[email-masked]>>; Tony Li <[email-masked]
>     <mailto:[email-masked]>>; Shraddha Hegde
>      > <[email-masked] <mailto:[email-masked]>>
>      > | > That's a pretty clever comparison indeed. I had a feeling it
>     will come
>      > | > In LSPs or LSA flooding you have a bunch of mechanisms to
>     make sure the
>      > | > and does not time out. And the default refresh in ISIS if I
>     recall was
>      > | > Can't you run OSPF over GRE ? For ISIS Henk had proposal not
>     so long ago
>      > | create GRE tunnels to all PEs that need the pulses? Nah, that
>     would be an
>      > | ugly requirement.
>      > |
>      > | thanks,
>      > | Peter
>      > |
>      > |
>      > | >
>     [email-masked] <mailto:[email-masked]>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 1 Dec 2021 16:10:33 +0100

> reliability and one pulse basically tearing the session for another

I don't think so. The PULSE can be sent *only* when every router in an area
removed all links going to a dead PE. Not when ABR noticed first such
flooded removal. That would be a severe bug.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 1 Dec 2021 16:36:20 +0100

Peter and Les,

Do you plan to have a provision to suspend PULSE generation for the planned
maintenance windows where service reachability was removed before PE went
down ?

What was the conclusion in respect to MAX AGE and OL bits ?

Thx,
R.

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 1 Dec 2021 16:57:41 +0100

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-masked]> wrote:

> >      > From: Hannes Gredler <[email-masked] <mailto:[email-masked]
> >>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 1 Dec 2021 17:04:35 +0100

Hi Tony,

On #2 I you are right in the case of src L1 getting partitioned. Yes it
will kill anycast design. If this is showstopper ... not sure. AFAIK only
sourcing ABRs need to keep track about all links to PE to be down. That
requirement does not propagate any further upstream.

Thx

On Wed, Dec 1, 2021 at 4:58 PM Tony Przygienda <[email-masked]> wrote:

>> >      > Cc: Robert Raszuk <[email-masked] <mailto:[email-masked]
>> >>;
>> >     Les Ginsberg (ginsberg)

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 1 Dec 2021 16:52:30 +0000

Tony –

From: Tony Przygienda <[email-masked]>
Sent: Wednesday, December 1, 2021 7:58 AM
To: Peter Psenak (ppsenak) <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; Hannes Gredler <[email-masked]>; lsr <[email-masked]>; Tony Li <[email-masked]>; Aijun Wang <[email-masked]>; Robert Raszuk <[email-masked]>; Shraddha Hegde <[email-masked]>
Subject: Re: [Lsr] BGP vs PUA/PULSE

1. my question is different. why does the draft say that seqnr# & IDs have to be preserved between restarts

[LES:] Section 4.3.1 of the draft tries to answer your question – but there is no mention of “restart” there.
There is in fact no mention of restart anywhere in the draft other than to say pulses are not preserved across restarts.

WE only retain the sequence #’s to make it easier to identify a new Pulse LSP from a retransmission.

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 ...

[LES:] We are not trying to handle the area partition case.
In such a case, even if nothing is done, traffic will flow via both ABRs and half of it will be dropped – so one could argue that switching BGP traffic to the backup path is still a good idea.

   Les

-=--- tony

On Wed, Dec 1, 2021 at 4:00 PM Peter Psenak <[email-masked]<mailto:[email-masked]>> wrote:
Tony,

yes.

thanks,
Peter

> <ginsberg=[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     Hannes -
>
>     Please see
>      > From: Hannes Gredler <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>      > To: Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>
>      > Cc: Robert Raszuk <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>;
>     Les Ginsberg (ginsberg)
>      > <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>; Aijun Wang
>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>; lsr
>      > <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>; Tony Li <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>; Shraddha Hegde
>      > <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 1 Dec 2021 16:58:30 +0000

Robert –

Regarding OL bit, normal SPF procedures are used. For destinations which transit the router that path will no longer be used. If that makes a given destination unreachable then a pulse will be generated.
For prefixes advertised by the OL Router, those are still considered reachable.
Implementations may have knobs to withdraw prefix advertisements when OL bit is set. If that occurs, again – normal SPF procedures are used.

Regarding max-metric, I do not see that it is relevant. Operators who use max-metric as part of their maintenance procedures are not taking a router completely out of service – they are simply making it a path of last resort.
If they want to take the node out of service they are going to have to shut links or disable protocol operation entirely on those links. So again I do not see that any special consideration of max-metric is needed.

    Les

From: Robert Raszuk <[email-masked]>
Sent: Wednesday, December 1, 2021 7:36 AM
To: Peter Psenak (ppsenak) <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>
Cc: lsr <[email-masked]>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Peter and Les,

Do you plan to have a provision to suspend PULSE generation for the planned maintenance windows where service reachability was removed before PE went down ?

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 1 Dec 2021 18:02:22 +0100

Hi Les,

*so one could argue that switching BGP traffic to the backup path is still
> a good idea.*

Well you are making a huge assumption that there is a backup path via a
given domain.

In  modern networks true backup is build from CE POV and happens via
another domain or via another service. Old fashioned design is stuck with
the model of single provider locking customers. That's no longer sound.

In such cases signalling PULSES adds only noise and not much benefit (other
than few seconds of less traffic to be dropped after traversing the given
domain network).

Best,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 1 Dec 2021 18:06:15 +0100

Les,

For all maintenance purposes there is need to drain the traffic from the
router before hitting reload or powering it off.

Sure services can be removed for that. But since Peter claims we need to
care about networks where no BGP is used how do I indicate domain wide that
I am going to bring the box down gracefully when it still is forwarding
packets in flight such that ingress points can gracefully switch it to a
backup paths.

To me PULSE could fit that bill. But it seems you are resisting to use it
in such way. So the question stands - how to do it ?

Thx,
R.

On Wed, Dec 1, 2021 at 5:58 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> Robert –
>
>
>
> Regarding OL bit, normal SPF procedures are used. For destinations which
> transit the router that path will no longer be used. If that makes a given
> destination unreachable then a pulse will be generated.
>
> Implementations may have knobs to withdraw prefix advertisements when OL
> bit is set. If that occurs, again – normal SPF procedures are used.
>
>
>
> Regarding max-metric, I do not see that it is relevant. Operators who use
> max-metric as part of their maintenance procedures are not taking a router
> completely out of service – they are simply making it a path of last resort.
>
> If they want to take the node out of service they are going to have to
> shut links or disable protocol operation entirely on those links. So again
> I do not see that any special consideration of max-metric is needed.
>
>
>
>     Les
>
>
>
>
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Wednesday, December 1, 2021 7:36 AM
> *To:* Peter Psenak (ppsenak) <[email-masked]>; Les Ginsberg (ginsberg)
> <[email-masked]>
> *Cc:* lsr <[email-masked]>
> *Subject:* Re: [Lsr] BGP vs PUA/PULSE
>
>
>
> Peter and Les,
>
>
>
> Do you plan to have a provision to suspend PULSE generation for the
> planned maintenance windows where service reachability was removed
> before PE went down ?
>
>
>

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 1 Dec 2021 18:32:41 +0100

"

Nodes which originate FSP-LSPs MUST
   remember the last sequence number used for a given FSP-LSP and
   increment the sequence number when generating a new version.

   FSP-LSP generation SHOULD utilize the "next" FSP-LSP ID each time new
   pulse information needs to be advertised i.e., if the most recent
   FSP-LSP ID used was A-00.n, the next set of pulse information SHOULD
   be advertised using FSP-LSP.ID A-00.n+1.  This minimizes the
   possibility of confusion if other routers in the network have not yet
   removed A-00.n from their LSPDB.
"

So you tell me I onver-interpreted as "between restarts" ;-) OK, fine.
Fair 'nuff. Maybe add one sentence clarification.

Otherwise yeah, I'd like the draft to add the "in case of partition
things may break but it's not much worse than before" ;-) and
"assumption is that the overlay will retry after dropping session on
negative so no positives are needed" and I'm ok with this thread.

my big gripe about "don't do it in main ISIS, take service instance"
remains though due to scalability concerns that bunch of senior folks
here raised already

-- tony

On Wed, Dec 1, 2021 at 5:52 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> Tony –
>
>
>
>
>
> *From:* Tony Przygienda <[email-masked]>
> *Sent:* Wednesday, December 1, 2021 7:58 AM
> *To:* Peter Psenak (ppsenak) <[email-masked]>
> *Cc:* Les Ginsberg (ginsberg) <[email-masked]>; Hannes Gredler <
> [email-masked]>; lsr <[email-masked]>; Tony Li <[email-masked]>; Aijun
> Wang <[email-masked]>; Robert Raszuk <[email-masked]>;
> Shraddha Hegde <[email-masked]>
> *[LES:] Section 4.3.1 of the draft tries to answer your question – but
> there is no mention of “restart” there.*
>
> *There is in fact no mention of restart anywhere in the draft other than
> to say pulses are not preserved across restarts.*
>
>
>
> *WE only retain the sequence #’s to make it easier to identify a new Pulse
> LSP from a retransmission.*
>
>
>
>
>
> *[LES:] We are not trying to handle the area partition case.*
>
> *In such a case, even if nothing is done, traffic will flow via both ABRs
> and half of it will be dropped – so one could argue that switching BGP
> traffic to the backup path is still a good idea.*
>
>
>
> *   Les*
>
>
>
> -=--- tony
>
>
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 1 Dec 2021 19:01:33 +0000

Robert –

Pulse functionality will need to be enabled by the user – as with any other IGP feature.
If a given customer does not see that it is useful in their network, they need not enable it.

If they have enabled it my comment regarding  partition still applies.

Thanx.

   Les

From: Robert Raszuk <[email-masked]>
Sent: Wednesday, December 1, 2021 9:02 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Tony Przygienda <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>; Hannes Gredler <[email-masked]>; lsr <[email-masked]>; Tony Li <[email-masked]>; Aijun Wang <[email-masked]>; Shraddha Hegde <[email-masked]>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Hi Les,

so one could argue that switching BGP traffic to the backup path is still a good idea.

Well you are making a huge assumption that there is a backup path via a given domain.

In  modern networks true backup is build from CE POV and happens via another domain or via another service. Old fashioned design is stuck with the model of single provider locking customers. That's no longer sound.

In such cases signalling PULSES adds only noise and not much benefit (other than few seconds of less traffic to be dropped after traversing the given domain network).

Best,
R.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 1 Dec 2021 19:05:12 +0000

Robert –

We have not made nor do we require any change to customer maintenance procedures.
Implementations have tools to address this. If you are not happy with those tools that is another topic entirely unrelated to pulse.

I stand by my responses below.

  Les

From: Robert Raszuk <[email-masked]>
Sent: Wednesday, December 1, 2021 9:06 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Peter Psenak (ppsenak) <[email-masked]>; lsr <[email-masked]>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Les,

For all maintenance purposes there is need to drain the traffic from the router before hitting reload or powering it off.

Sure services can be removed for that. But since Peter claims we need to care about networks where no BGP is used how do I indicate domain wide that I am going to bring the box down gracefully when it still is forwarding packets in flight such that ingress points can gracefully switch it to a backup paths.

To me PULSE could fit that bill. But it seems you are resisting to use it in such way. So the question stands - how to do it ?

Thx,
R.

On Wed, Dec 1, 2021 at 5:58 PM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Robert –

    Les

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, December 1, 2021 7:36 AM
To: Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>; Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: lsr <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Peter and Les,

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 1 Dec 2021 20:11:59 +0100

Les,

> Pulse functionality will need to be enabled by the user – as with any
other IGP feature.

That was not my point.

My point was that you blindly PULSE irrespective if this is useful for
anyone if a given PE went down. That is an architectural flaw.

Best,
R.

On Wed, Dec 1, 2021 at 8:02 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> *Sent:* Wednesday, December 1, 2021 9:02 AM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>
> *Cc:* Tony Przygienda <[email-masked]>; Peter Psenak (ppsenak) <
> [email-masked]>; Hannes Gredler <[email-masked]>; lsr <[email-masked]>;
> Tony Li <[email-masked]>; Aijun Wang <[email-masked]>;
> In such cases signalling PULSES adds only noise and not much benefit
> (other than few seconds of less traffic to be dropped after traversing the
> given domain network).
>
>
>
> Best,
>
> R.
>
>
>
>
>
>
>
>
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 1 Dec 2021 19:13:40 +0000

Tony –

Inline.

From: Tony Przygienda <[email-masked]>
Sent: Wednesday, December 1, 2021 9:33 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Peter Psenak (ppsenak) <[email-masked]>; Hannes Gredler <[email-masked]>; lsr <[email-masked]>; Tony Li <[email-masked]>; Aijun Wang <[email-masked]>; Robert Raszuk <[email-masked]>; Shraddha Hegde <[email-masked]>
Subject: Re: [Lsr] BGP vs PUA/PULSE

"

   be advertised using FSP-LSP.ID<http://FSP-LSP.ID> A-00.n+1.  This minimizes the

So you tell me I onver-interpreted as "between restarts" ;-) OK, fine. Fair 'nuff. Maybe add one sentence clarification.

[LES:] Sure.

Otherwise yeah, I'd like the draft to add the "in case of partition things may break but it's not much worse than before" ;-) and "assumption is that the overlay will retry after dropping session on negative so no positives are needed" and I'm ok with this thread.

[LES:] I think significantly more needs to be said about the current use case for event notification – and this point can be part of that. Look for that in the next revision of the draft.

my big gripe about "don't do it in main ISIS, take service instance" remains though due to scalability concerns that bunch of senior folks here raised already

[LES:] I am not in favor of a separate instance in this case. Reason being all of the information required to determine when to send pulses is already known by the main instance. Moving the pulse advertisements themselves to a separate instance would likely be more costly in resources on the routers themselves than advertising them in the main instance. Scale considerations need to be addressed – as has been stated in this and earlier threads many times – and that would be true regardless of whether we used the main instance or a separate instance.

There is also the point made by Greg Mirsky early on in this discussion – that the use of event-notification needs to be carefully limited to cases that make sense for the main routing instance. The next revision of the draft will also address this point.

    Les

-- tony

On Wed, Dec 1, 2021 at 5:52 PM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Tony –

From: Tony Przygienda <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, December 1, 2021 7:58 AM
To: Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>
Cc: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; Hannes Gredler <[email-masked]<mailto:[email-masked]>>; lsr <[email-masked]<mailto:[email-masked]>>; Tony Li <[email-masked]<mailto:[email-masked]>>; Aijun Wang <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] BGP vs PUA/PULSE

   Les

-=--- tony

yes.

thanks,
Peter

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 1 Dec 2021 19:18:41 +0000

Robert –

One last time…inline.

Sent: Wednesday, December 1, 2021 11:12 AM

Les,

That was not my point.

My point was that you blindly PULSE irrespective if this is useful for anyone if a given PE went down. That is an architectural flaw.
[LES:] Only if the feature is enabled.
You have described a network where there is nothing useful that can be done in reaction to the pulse (or at least the operator believes that to be true).
IN such a case do not enable the feature.

We are providing another tool – it is in the hands of the operators as to when to use it.

   Les

Best,
R.

On Wed, Dec 1, 2021 at 8:02 PM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Robert –

Thanx.

   Les

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, December 1, 2021 9:02 AM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: Tony Przygienda <[email-masked]<mailto:[email-masked]>>; Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>; Hannes Gredler <[email-masked]<mailto:[email-masked]>>; lsr <[email-masked]<mailto:[email-masked]>>; Tony Li <[email-masked]<mailto:[email-masked]>>; Aijun Wang <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Hi Les,

Best,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 1 Dec 2021 20:23:13 +0100

No Les I do not understand why you are not getting my point.

Network is not black or white. Some PEs may be servicing multihomed
customers and some (think 5G towers) would always be servicing single home
smartphones.

Why build a mechanism which does not allow clean separation of what we
leak/pulse ?

You mentioned use TAGs ... but that would be coarse and very static.

Folks suggested to you that potential clients should register and only then
get the information - but what was said on that was - "Oh we do not know
how to do it in IGP".

Then maybe it is time to go back to the whiteboard and do some innovations
to make sure feature is useful and harmless ?

Best,
R.

On Wed, Dec 1, 2021 at 8:18 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> *Sent:* Wednesday, December 1, 2021 11:12 AM
> *[LES:] Only if the feature is enabled.*
>
> *You have described a network where there is nothing useful that can be
> done in reaction to the pulse (or at least the operator believes that to be
> true).*
>
> *IN such a case do not enable the feature.*
>
>
>
> *We are providing another tool – it is in the hands of the operators as to
> when to use it.*
>
>
>
> *   Les*
>
>
>
> Best,
>
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 1 Dec 2021 21:25:53 +0100

Hi Tony,

I have been thinking about your email a bit more. Actually the destructive
issue you have described can happen not only in the case of partitioned L1
areas.

*Deployment scenario: *

It is quite often the case that ABRs connectivity intra-area are very
different to their inter-as connections. That usually means that different
line cards are used to connect to other routers in the local area then
those in the core area.

So when anything happens to the line card which connects L1 (for example it
goes down, there is massive congestion, protocol queue is full etc ...)
when previously received LSPs expire such ABR may trigger PULSE of all PE
routers domain wide. And all the fuses discussed to prevent massive
flooding will not kick in as there may be just say 10 PEs in the area - all
working just fine.

The other ABRs will happily continue to inject summaries but service stops
for configured PULSE timeout (as discussed 200 sec). Note that it is full
service stop not switching to a backup path as all PEs in the area PULSED
domain wide. Not good.

I have not seen any discussion about such a failure case so far. And only
your mail triggered it !

Many thx,
R.

On Wed, Dec 1, 2021 at 5:04 PM Robert Raszuk <[email-masked]> wrote:

>>> >      > | the database. The only difference with the Pulse LSP is that
>>> it
>>> >     is not

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 1 Dec 2021 21:41:51 +0100

Apologies 2 corrections:

1)  s/to their inter-as/ to their inter-area/

2)  "service stops for configured PULSE timeout (as discussed 200 sec)."
Actually in the described case it is much worse ... Service stops forever
to such area as service layer may not be at all aware about this kind of
false positive !

Btw this is also not an implementation detail as all multi vendor ABRs
better work in the same manner.

And the robust solution to this case seems to be along the lines of the
logic you have described. PULSES must be acted on by L2 ABRs or by remote
PEs *only* when all sources of the summaries inject identical PULSE.

That makes the feature a bit more complex ....

Thx,
R.

On Wed, Dec 1, 2021 at 9:25 PM Robert Raszuk <[email-masked]> wrote:

> So when anything happens to the line card which connects L1 (for example
> it goes down, there is massive congestion, protocol queue is full etc ...)
>>>> >      > | If I send the LSP with the lifetime of 1 min, there will
>>>> never
>>>> >     be any

---

From: Aijun Wang <[email-masked]>
Date: Thu, 2 Dec 2021 07:58:41 +0800

Hi, Robert:

Aijun Wang
China Telecom

> On Dec 2, 2021, at 04:42, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Apologies 2 corrections:
> 
> 2)  "service stops for configured PULSE timeout (as discussed 200 sec)."  Actually in the described case it is much worse ... Service stops forever to such area as service layer may not be at all aware about this kind of false positive ! 
> 
> Btw this is also not an implementation detail as all multi vendor ABRs better work in the same manner. 
> 
> And the robust solution to this case seems to be along the lines of the logic you have described. PULSES must be acted on by L2 ABRs or by remote PEs *only* when all sources of the summaries inject identical PULSE. 

[WAJ] https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08#section-4 has described such situations. I have also introduced it in the IETF 112 meeting.
Please see the last paragraph of this section.

>> I have been thinking about your email a bit more. Actually the destructive issue you have described can happen not only in the case of partitioned L1 areas. 
>> 
>> Deployment scenario: 
>> 
>> It is quite often the case that ABRs connectivity intra-area are very different to their inter-as connections. That usually means that different line cards are used to connect to other routers in the local area then those in the core area. 
>> 
>> So when anything happens to the line card which connects L1 (for example it goes down, there is massive congestion, protocol queue is full etc ...) when previously received LSPs expire such ABR may trigger PULSE of all PE routers domain wide. And all the fuses discussed to prevent massive flooding will not kick in as there may be just say 10 PEs in the area - all working just fine. 
>> 
>> The other ABRs will happily continue to inject summaries but service stops for configured PULSE timeout (as discussed 200 sec). Note that it is full service stop not switching to a backup path as all PEs in the area PULSED domain wide. Not good. 
>> 
>> I have not seen any discussion about such a failure case so far. And only your mail triggered it ! 
>> 
>> Many thx,
>> R.
>> 
>> 
>> 
>>> On #2 I you are right in the case of src L1 getting partitioned. Yes it will kill anycast design. If this is showstopper ... not sure. AFAIK only sourcing ABRs need to keep track about all links to PE to be down. That requirement does not propagate any further upstream. 
>>> 
>>> Thx
>>>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 2 Dec 2021 01:12:33 +0100

Hi Aijun,

If you meant that paragraph:

   When only some of the ABRs can't reach the failure node/link, as that
   described in Section 3.2, the ABR that can reach the PUAM prefix
   should advertise one specific route to this PUAM prefix.  The
   internal routers within another area can then bypass the ABRs that
   can't reach the PUAM prefix, to reach the PUAM prefix.

If this is it then I think this is the worst possible idea. Moreover it
does not even work as PUA/PULSE have already propagated to remote PEs and
did "the damage". Remote PEs are sitting and waiting for the service layer
to reconverge.

You are now asking for self ABR to ABR state synchronization (even if by
only keepin an ear open to other ABR's PUAs) and based on that host route
injection and domain wide leaking of those artificial host routes by other
ABRs from a given area which not only does not help but will cause even
more churn domain wide.

I can think of a few much more elegant solutions, but I will let PULSE
authors come up with their own ideas :)

- -

Bottom line is that (putting aside all concerns already voiced by folks on
this list) both PULSE & PUA ideas perhaps can be made to work for the case
where PE really goes down.

However, to make it work in situations where ABRs just think PEs are down
but they are not, ie. by false positive DOWN events flooded domain wide -
the entire concept becomes much harder to handle in an elegant and scalable
way. And what I illustrated as the reasons for such scenarios is just tip
of the iceberg in pile of reasons why ABR may think PEs went down. There
are many more...

Kind regards,
Robert

On Thu, Dec 2, 2021 at 12:58 AM Aijun Wang <[email-masked]>
wrote:

> [WAJ]
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08#section-4 has
> described such situations. I have also introduced it in the IETF 112
> meeting.
>> I have been thinking about your email a bit more. Actually the
>> destructive issue you have described can happen not only in the case of
>> partitioned L1 areas.
>>
>> *Deployment scenario: *
>>
>> The other ABRs will happily continue to inject summaries but service
>> stops for configured PULSE timeout (as discussed 200 sec). Note that it is
>> full service stop not switching to a backup path as all PEs in the area
>> PULSED domain wide. Not good.
>>

---

From: Aijun Wang <[email-masked]>
Date: Thu, 2 Dec 2021 08:43:11 +0800

Hi, Robert:

Aijun Wang
China Telecom

> On Dec 2, 2021, at 08:13, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Hi Aijun,
> 
> If this is it then I think this is the worst possible idea. Moreover it does not even work as PUA/PULSE have already propagated to remote PEs and did "the damage". Remote PEs are sitting and waiting for the service layer to reconverge. 

[WAJ] No, please the paragraph before it. The internal router will act only when it receives the PUA from all of its ABR.

   If the nodes in the area receive the PUAM flood from all of its ABR
   routers, they will start BGP convergence process if there exist BGP
   session on this PUAM prefix.  The PUAM creates a forced fail over
   action to initiate immediate control plane convergence switchover to
   alternate egress PE.  Without the PUAM forced convergence the down
   prefix will yield black hole routing resulting in loss of
   connectivity.

> 
> You are now asking for self ABR to ABR state synchronization (even if by only keepin an ear open to other ABR's PUAs) and based on that host route injection and domain wide leaking of those artificial host routes by other ABRs from a given area which not only does not help but will cause even more churn domain wide. 

[WAJ] No, not domain wide. The ABR sit another area border will advertise only the summary address that includes the detail prefix.
 
> 
> I can think of a few much more elegant solutions, but I will let PULSE authors come up with their own ideas :) 
> 
> - - 
> 
> Bottom line is that (putting aside all concerns already voiced by folks on this list) both PULSE & PUA ideas perhaps can be made to work for the case where PE really goes down. 
> 
> However, to make it work in situations where ABRs just think PEs are down but they are not, ie. by false positive DOWN events flooded domain wide - the entire concept becomes much harder to handle in an elegant and scalable way. And what I illustrated as the reasons for such scenarios is just tip of the iceberg in pile of reasons why ABR may think PEs went down. There are many more... 

[WAJ] The key criteria is that the ABR can’t reach the mentioned PE. PE DOWN is only one kind of them. The OL bit set by the transit router may be other, the links to this PE are  broken is another. Then actually PUA doesn’t care the liveness of the PE, as Tony Li’s comments. The ABR cares mainly the “unreachable” status of the PE.

> 
> Kind regards,
> Robert
> 
> 
>> On Thu, Dec 2, 2021 at 12:58 AM Aijun Wang <[email-masked]> wrote:
>> Hi, Robert:
>> 
>> Aijun Wang
>> China Telecom
>>

---

From: Peter Psenak <[email-masked]>
Date: Thu, 2 Dec 2021 10:25:30 +0100

On 01/12/2021 21:41, Robert Raszuk wrote:
> 2)  "service stops for configured PULSE timeout (as discussed 200 
> sec)."  Actually in the described case it is much worse ... Service 
> stops forever to such area as service layer may not be at all aware 
> about this kind of false positive !

I don't understand what "service stops" you are talking about. Pulse 
will never stop any service. It will at most trigger the switch to 
alternate service source. If there is none available, nothing will happen.

> logic you have described. PULSES must be acted on by L2 ABRs or by 
> remote PEs *only* when all sources of the summaries inject identical PULSE.

not really, you can act on first one and ignore the same pulse from 
other source that comes later. Unless the area partition case the first 
pulse is guaranteed to mean the destination is unreachable. For area 
partition case the pulse may trigger the switch to alternate source of 
service, which is a good thing as has been described earlier.

Peter

> On Wed, Dec 1, 2021 at 9:25 PM Robert Raszuk <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi Tony,
> 
>     destructive issue you have described can happen not only in the case
>     of partitioned L1 areas.
> 
>     *Deployment scenario: *
> 
>     It is quite often the case that ABRs connectivity intra-area are
>     very different to their inter-as connections. That usually means
>     that different line cards are used to connect to other routers in
>     the local area then those in the core area.
> 
>     So when anything happens to the line card which connects L1 (for
>     example it goes down, there is massive congestion, protocol queue is
>     full etc ...) when previously received LSPs expire such ABR may
>     trigger PULSE of all PE routers domain wide. And all the fuses
>     discussed to prevent massive flooding will not kick in as there may
>     be just say 10 PEs in the area - all working just fine.
> 
>     stops for configured PULSE timeout (as discussed 200 sec). Note that
>     it is full service stop not switching to a backup path as all PEs in
>     the area PULSED domain wide. Not good.
> 
>     On Wed, Dec 1, 2021 at 5:04 PM Robert Raszuk <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         Hi Tony,
> 
>         On #2 I you are right in the case of src L1 getting partitioned.
>         Yes it will kill anycast design. If this is showstopper ... not
>         sure. AFAIK only sourcing ABRs need to keep track about all
>         links to PE to be down. That requirement does not propagate any
>         further upstream.
> 
>         Thx
> 
>         On Wed, Dec 1, 2021 at 4:58 PM Tony Przygienda
>         <[email-masked] <mailto:[email-masked]>> wrote:
> 
>             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-masked] <mailto:[email-masked]>> wrote:
> 
>                 Tony,
> 
>                 <mailto:[email-masked]>
>                  > <mailto:[email-masked]
>                 <mailto:[email-masked]>>> wrote:
>                  >
>                  >     Hannes -
>                  >
>                  >     Please see
>                  >
>                  >      > -----Original Message-----
>                  >      > From: Hannes Gredler <[email-masked]
>                 <mailto:[email-masked]> <mailto:[email-masked]
>                 <mailto:[email-masked]>>>
>                  >      > Sent: Tuesday, November 30, 2021 11:22 AM
>                  >      > To: Peter Psenak (ppsenak) <[email-masked]
>                 <mailto:[email-masked]>
>                  >      > Cc: Robert Raszuk <[email-masked]
>                 <mailto:[email-masked]> <mailto:[email-masked]
>                 <mailto:[email-masked]>>>;
>                  >     Les Ginsberg (ginsberg)
>                  >      > <[email-masked]
>                 <mailto:[email-masked]> <mailto:[email-masked]
>                 <mailto:[email-masked]>>>; Aijun Wang
>                  >     <[email-masked]
>                 <mailto:[email-masked]>
>                 <mailto:[email-masked]
>                 <mailto:[email-masked]>>>; lsr
>                  >      > <[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>>; Tony Li
>                 <[email-masked] <mailto:[email-masked]>
>                  >     <mailto:[email-masked]
>                 <mailto:[email-masked]>>>; Shraddha Hegde
>                  >      > <[email-masked]
>                 <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>>
>                  >      > 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.
>                  >      > | >
>                  >
>                  >      > 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.
>                  >      > |
>                  >
>                 <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 2 Dec 2021 10:33:33 +0100

Hey Peter,

> alternate service source. If there is none available, nothing will happen.

Oh really ? Is that so ? That's not what you have been saying all along by
stating that PULSE will bring down IPSec Tunnel. Same for BGP based
services.

If I receive a PULSE stating that my PE is down why would I continue to
pump Gb/s data to such PE even if there is only single BGP path to it.

> pulse is guaranteed to mean the destination is unreachable.

Absolutely not. I cam have control plane issue on the ABRs while data plane
works fine. Needless to say while all PEs work fine as well.

> For area

I am not that much worried (as alluded to Tony P)  for the local area
partitioned case. I am much more worried about false positive PULSE.

See this is a knife without the ability to self heal the wound.

Best,
R.

---

From: Peter Psenak <[email-masked]>
Date: Thu, 2 Dec 2021 10:41:06 +0100

On 02/12/2021 10:33, Robert Raszuk wrote:
> Oh really ? Is that so ? That's not what you have been saying all along 
> by stating that PULSE will bring down IPSec Tunnel. Same for BGP based 
> services.

Pulse does not replace the overlay protocols functionality. They are the 
ultimate source of the trust. Pulse is just an indication that something 
may be going wrong an overlay protocols may switch to alternate source 
if there are any.

> pump Gb/s data to such PE even if there is only single BGP path to it.

I don't see a problem. Without the pulse that is what will happen 
anyway, until the overlay detects the loss of the service.

> Absolutely not. I cam have control plane issue on the ABRs while data 
> plane works fine. Needless to say while all PEs work fine as well.

if you have control plane issue on ABR you are busted anyway, we are not 
after that case.

Peter

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 2 Dec 2021 10:54:40 +0100

Peter,

> ultimate source of the trust.

The entire point of PULSE is to speed up the process of service and
connectivity restoration. You can't just back off from it now and say that
it is all up to overlay to discontinue using single path to a service.

> Pulse is just an indication that something

Too many "may(s) ..."  here.

> anyway, until the overlay detects the loss of the service.

That is not the point.

If we are to standardize something in this space it is IMO much better for
it to be rock solid and useful.

Not just a lightweight indication that PE may perhaps went down, but we are
not sure.

> if you have control plane issue on ABR you are busted anyway, we are not

Nope I am not busted if ABR's data plane still works fine and summary
attracts traffic to it. If control plane dies summary will be removed but
my end to end service will not be impacted at all (it will continue happily
via other ABRs to the area).

But if ingress PE implementation will stop the service based on the fake
PULSE while service layer has no clue about it that is pretty nasty.

Cheers,
R.

PS. And there is also the risk of insider attack injecting those PULSES -
but I am sure if this topic continues solid security review will take care
of it :)  Yes I know - if you let anyone inject anything like this to your
IGP or BGP you have bigger problems but things happen ... sometimes by
unplanned accidents.

---

From: Aijun Wang <[email-masked]>
Date: Thu, 2 Dec 2021 18:44:34 +0800

Hi,Robert:

Aijun Wang
China Telecom

> On Dec 2, 2021, at 17:55, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Peter,
>  
> The entire point of PULSE is to speed up the process of service and connectivity restoration. You can't just back off from it now and say that it is all up to overlay to discontinue using single path to a service. 
>  
> If we are to standardize something in this space it is IMO much better for it to be rock solid and useful. 
> 
> Not just a lightweight indication that PE may perhaps went down, but we are not sure. 
>  
> Nope I am not busted if ABR's data plane still works fine and summary attracts traffic to it. If control plane dies summary will be removed but my end to end service will not be impacted at all (it will continue happily via other ABRs to the area). 
[WAJ] The PE should only switchover the overlay service when it receives the “DOWN” message from all of its ABRs.
> 
> But if ingress PE implementation will stop the service based on the fake PULSE while service layer has no clue about it that is pretty nasty.
> 
> Cheers,
> R.
> 
> PS. And there is also the risk of insider attack injecting those PULSES - but I am sure if this topic continues solid security review will take care of it :)  Yes I know - if you let anyone inject anything like this to your IGP or BGP you have bigger problems but things happen ... sometimes by unplanned accidents. 

[WAJ] Same as above explanation, then only one accident or injecting “DOWN” will not trigger the switchover of overlay service.

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 2 Dec 2021 11:49:56 +0100

Idly thinking about the stuff more and more issues pop up that confirm my
initial gut feeling that the pulse stuff is simply not what IGP can do
reasonably (i.e. liveliness). negative as liveliness indication is arguably
even worse ;-) but I think most of us agreed on that across those hundreds
of emails by now.

So, to expound a bit. IGP reachability which IGP does normally is _very_
different from liveliness and here's another example (I describe it in
principle but people who deployed stuff will know what scenarios I'm
talking about)

So, in short, the fact that an IGP, let's say ABR, advertises a summary has
_nothing_ to do much with liveliness of what it summarizes in system wide
sense. In more specifics, even when this aggregate goes away or IGP cannot
compute _reachability_ to a specific address/node does NOT mean that the
prefix advertised by such node is not _alive_.

Imagine (often done in fact in deployments I dealt with) that the prefix
advertised by a node into IGP is not _reachable_ by IGP all of a sudden,
simplest case being a link loss of course. However, it is in the system
still reachable by means e.g. of a default route from another protocol or a
specific route (static?) over a link IGP is not running on. Now, if IGP
starts to pulse it will defeat the very purpose of such backup.

And no, you cannot "know" whether backup is here, there are even funky
cases where a policy only installs a backup route if the primary went away
which may be fast enough to keep e.g. TCP up (whether it's the best
possible architecture is disputable but it's a fact of live that such stuff
exists).

So, basically we try to invent "liveliness indication" in IGP whereas IGP
cannot be aware whether the prefix is reachable system-wide through it even
when IGP lost _reachability_.

And yes, before we go there, I know that with enough "limited domain" and
"limited scale" and "limited use case" arguments anything one can imagine
"works" ...

--- tony

On Wed, Dec 1, 2021 at 8:13 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> *Sent:* Wednesday, December 1, 2021 9:33 AM
> *Cc:* Peter Psenak (ppsenak) <[email-masked]>; Hannes Gredler <
> *[LES:] Sure.*
> *[LES:] I think significantly more needs to be said about the current use case for event notification – and this point can be part of that. Look for that in the next revision of the draft.*
>
> *[LES:] I am not in favor of a separate instance in this case. Reason being all of the information required to determine when to send pulses is already known by the main instance. Moving the pulse advertisements themselves to a separate instance would likely be more costly in resources on the routers themselves than advertising them in the main instance. Scale considerations need to be addressed – as has been stated in this and earlier threads many times – and that would be true regardless of whether we used the main instance or a separate instance. *
>
> *There is also the point made by Greg Mirsky early on in this discussion – that the use of event-notification needs to be carefully limited to cases that make sense for the main routing instance. The next revision of the draft will also address this point.*
>
> *    Les*
>
> -- tony
>
>
>

---

From: Aijun Wang <[email-masked]>
Date: Thu, 2 Dec 2021 20:04:56 +0800

Hi, Tony:

Aijun Wang
China Telecom

> On Dec 2, 2021, at 18:51, Tony Przygienda <[email-masked]> wrote:
> 
> 
> Idly thinking about the stuff more and more issues pop up that confirm my initial gut feeling that the pulse stuff is simply not what IGP can do reasonably (i.e. liveliness). negative as liveliness indication is arguably even worse ;-) but I think most of us agreed on that across those hundreds of emails by now. 
> 
> So, to expound a bit. IGP reachability which IGP does normally is _very_ different from liveliness and here's another example (I describe it in principle but people who deployed stuff will know what scenarios I'm talking about) 
> 
> So, in short, the fact that an IGP, let's say ABR, advertises a summary has _nothing_ to do much with liveliness of what it summarizes in system wide sense. In more specifics, even when this aggregate goes away or IGP cannot compute _reachability_ to a specific address/node does NOT mean that the prefix advertised by such node is not _alive_. 

[WAJ] The “DOWN” state just indicate the mentioned prefixes is unreachable, not not_alive_.

> 
> Imagine (often done in fact in deployments I dealt with) that the prefix advertised by a node into IGP is not _reachable_ by IGP all of a sudden, simplest case being a link loss of course. However, it is in the system still reachable by means e.g. of a default route from another protocol or a specific route (static?) over a link IGP is not running on. Now, if IGP starts to pulse it will defeat the very purpose of such backup. 

[WAJ] Reachable or unreachable is based on the node’s route table, not the IGP itself.

> 
> And no, you cannot "know" whether backup is here, there are even funky cases where a policy only installs a backup route if the primary went away which may be fast enough to keep e.g. TCP up (whether it's the best possible architecture is disputable but it's a fact of live that such stuff exists). 

[WAJ] Consume of such information is depended on the receiving node itself. The “DOWN” information just give a indication  for the overlay service on top of the interested prefixes. 

> 
> So, basically we try to invent "liveliness indication" in IGP whereas IGP cannot be aware whether the prefix is reachable system-wide through it even when IGP lost _reachability_. 
[WAJ] The ABR have knowledge to know this.
> 
> And yes, before we go there, I know that with enough "limited domain" and "limited scale" and "limited use case" arguments anything one can imagine "works" ... 

[WAJ] IGP are all deployed in limited domain.

> 
> --- tony 
> 
>> On Wed, Dec 1, 2021 at 8:13 PM Les Ginsberg (ginsberg) <[email-masked]> wrote:
>> Tony –
>> 
>>  
>> 
>> Inline.
>> 
>>  
>> 
>> On Wed, Dec 1, 2021 at 5:52 PM Les Ginsberg (ginsberg) <[email-masked]> wrote:
>> 
>> Tony –
>> 
>>  
>> 
>>  
>>

---

From: Peter Psenak <[email-masked]>
Date: Thu, 2 Dec 2021 14:03:05 +0100

Tony,

On 02/12/2021 11:49, Tony Przygienda wrote:
> Idly thinking about the stuff more and more issues pop up that confirm 
> my initial gut feeling that the pulse stuff is simply not what IGP can 
> do reasonably (i.e. liveliness). negative as liveliness indication is 
> arguably even worse ;-) but I think most of us agreed on that across 
> those hundreds of emails by now.
> 
> So, in short, the fact that an IGP, let's say ABR, advertises a summary 
> has _nothing_ to do much with liveliness of what it summarizes in system 
> wide sense. In more specifics, even when this aggregate goes away or IGP 
> cannot compute _reachability_ to a specific address/node does NOT mean 
> that the prefix advertised by such node is not _alive_.
> 
> still reachable by means e.g. of a default route from another protocol 
> or a specific route (static?) over a link IGP is not running on. Now, if 
> IGP starts to pulse it will defeat the very purpose of such backup.

no less specific route will ever make something that went down 
reachable. The purpose of the pulse is not to defeat the purpose of the 
default, or less specific route. The purpose of the pulse is to notify 
interested clients that the reachability of some less specific route 
(typically a host route) that is covered by the summary in its source 
area is lost.

If a unique host route that was reachable in its source area became 
unreachable because its originator became unreachable, we know for sure 
that the host route is gone no matter what less specific routes may 
cover it.

> cases where a policy only installs a backup route if the primary went 
> away which may be fast enough to keep e.g. TCP up (whether it's the best 
> possible architecture is disputable but it's a fact of live that such 
> stuff exists).
> 
> So, basically we try to invent "liveliness indication" in IGP whereas 
> IGP cannot be aware whether the prefix is reachable system-wide through 
> it even when IGP lost _reachability_.

we can limit the pulse notification to host prefixes. That should 
address your concern.

thanks,
Peter

> 
> And yes, before we go there, I know that with enough "limited domain" 
> and "limited scale" and "limited use case" arguments anything one can 
> imagine "works" ...
> 
> --- tony
> 
> On Wed, Dec 1, 2021 at 8:13 PM Les Ginsberg (ginsberg) 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Tony –____
> 
>     __ __
> 
>     Inline.____
> 
>     __ __
> 
>     *From:* Tony Przygienda <[email-masked]
>     <mailto:[email-masked]>>
>     *To:* Les Ginsberg (ginsberg) <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* Peter Psenak (ppsenak) <[email-masked]
>     <mailto:[email-masked]>>; Hannes Gredler <[email-masked]
>     <mailto:[email-masked]>>; lsr <[email-masked]
>     <mailto:[email-masked]>>; Tony Li <[email-masked]
>     <mailto:[email-masked]>>; Aijun Wang <[email-masked]
>     <mailto:[email-masked]>>; Robert Raszuk
>     <[email-masked] <mailto:[email-masked]>>; Shraddha Hegde
>     *Subject:* Re: [Lsr] BGP vs PUA/PULSE____
> 
>     __ __
> 
>     "____
> 
>     Nodes which originate FSP-LSPs MUST____
> 
>         remember the last sequence number used for a given FSP-LSP and____
> 
>         increment the sequence number when generating a new version.____
> 
>     __  __
> 
>         FSP-LSP generation SHOULD utilize the "next" FSP-LSP ID each time new____
> 
>         pulse information needs to be advertised i.e., if the most recent____
> 
>         FSP-LSP ID used was A-00.n, the next set of pulse information SHOULD____
> 
>         be advertised usingFSP-LSP.ID  <http://FSP-LSP.ID>  A-00.n+1.  This minimizes the____
> 
>         possibility of confusion if other routers in the network have not yet____
> 
>     "____
>     So you tell me I onver-interpreted as "between restarts" ;-) OK, fine. Fair 'nuff. Maybe add one sentence clarification.____
> 
>     */[LES:] Sure./*____
> 
>     Otherwise yeah, I'd like the draft to add the "in case of partition things may break but it's not much worse than before" ;-) and "assumption is that the overlay will retry after dropping session on negative so no positives are needed" and I'm ok with this thread.____
> 
>     */[LES:] I think significantly more needs to be said about the
>     current use case for event notification – and this point can be part
>     of that. Look for that in the next revision of the draft./*____
> 
>     my big gripe about "don't do it in main ISIS, take service instance" remains though due to scalability concerns that bunch of senior folks here raised already____
> 
>     */[LES:] I am not in favor of a separate instance in this case.
>     Reason being all of the information required to determine when to
>     send pulses is already known by the main instance. Moving the pulse
>     advertisements themselves to a separate instance would likely be
>     more costly in resources on the routers themselves than advertising
>     them in the main instance. Scale considerations need to be addressed
>     – as has been stated in this and earlier threads many times – and
>     that would be true regardless of whether we used the main instance
>     or a separate instance. ____/*
> 
>     */There is also the point made by Greg Mirsky early on in this
>     discussion – that the use of event-notification needs to be
>     carefully limited to cases that make sense for the main routing
>     instance. The next revision of the draft will also address this
>     point.____/*
> 
>     */    Les/*____
> 
>     -- tony____
> 
>     __ __
> 
>     On Wed, Dec 1, 2021 at 5:52 PM Les Ginsberg (ginsberg)
>     <[email-masked] <mailto:[email-masked]>> wrote:____
> 
>         Tony –____
> 
>         ____
> 
>         ____
> 
>         *From:* Tony Przygienda <[email-masked]
>         <mailto:[email-masked]>>
>         *To:* Peter Psenak (ppsenak) <[email-masked]
>         *Cc:* Les Ginsberg (ginsberg) <[email-masked]
>         <mailto:[email-masked]>>; Hannes Gredler <[email-masked]
>         <mailto:[email-masked]>>; lsr <[email-masked]
>         <mailto:[email-masked]>>; Tony Li <[email-masked]
>         <mailto:[email-masked]>>; Aijun Wang <[email-masked]
>         <mailto:[email-masked]>>; Robert Raszuk
>         <[email-masked] <mailto:[email-masked]>>; Shraddha Hegde
>         *Subject:* Re: [Lsr] BGP vs PUA/PULSE____
> 
>         ____
> 
>         1. my question is different. why does the draft say that seqnr#
>         & IDs have to be preserved between restarts ____
> 
>         ____
> 
>         ____
> 
>         */[LES:] Section 4.3.1 of the draft tries to answer your
>         question – but there is no mention of “restart” there./*____
> 
>         */There is in fact no mention of restart anywhere in the draft
>         other than to say pulses are not preserved across restarts./*____
> 
>         *//*____
> 
>         */WE only retain the sequence #’s to make it easier to identify
>         a new Pulse LSP from a retransmission./*____
> 
>         *//*____
> 
>         *//*____
> 
>         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 ... ____
> 
>         ____
> 
>         */[LES:] We are not trying to handle the area partition case./*____
> 
>         */In such a case, even if nothing is done, traffic will flow via
>         both ABRs and half of it will be dropped – so one could argue
>         that switching BGP traffic to the backup path is still a good
>         idea./*____
> 
>         *//*____
> 
>         */   Les/*____
> 
>         ____
> 
>         -=--- tony ____
> 
>         ____
> 
>         On Wed, Dec 1, 2021 at 4:00 PM Peter Psenak <[email-masked]
>         <mailto:[email-masked]>> wrote:____
> 
>             Tony,
> 
>              >     <mailto:[email-masked] <mailto:[email-masked]>>>
>              >      > <[email-masked] <mailto:[email-masked]>
>             <mailto:[email-masked] <mailto:[email-masked]>>>;
>             Aijun Wang
>              >     <mailto:[email-masked] <mailto:[email-masked]>>>;
>             Shraddha Hegde
>              >      > <[email-masked]
>             <mailto:[email-masked]> <mailto:[email-masked]
>             <mailto:[email-masked]>>>
>              >      > On Tue, Nov 30, 2021 at 01:15:04PM +0100, Peter
>             Psenak wrote:
>              >      > | Hi Robert,
>              >      > |
>              >      > | > That's a pretty clever comparison indeed. I
>             had a feeling it
>              >     will come
>              >      > | > 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
>              >      > | > and does not time out. And the default refresh
>             in ISIS if I
>              >     recall was
>              >      > | 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
>              >      > | >     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
>              >      > | 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
>              > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>             <mailto:[email-masked]>>
>              > ____

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 2 Dec 2021 14:19:36 +0100

> The purpose of the pulse is to notify interested clients

How do you know that a client is interested in a given PULSE message ?

I am asking as this is one of my objections. If this is fixed please share
details.

Thx,
R.

On Thu, Dec 2, 2021 at 2:03 PM Peter Psenak <[email-masked]> wrote:

> >     So you tell me I onver-interpreted as "between restarts" ;-) OK,
> fine. Fair 'nuff. Maybe add one sentence clarification.____
> >
> >     */[LES:] Sure./*____
> >
> things may break but it's not much worse than before" ;-) and "assumption
> is that the overlay will retry after dropping session on negative so no
> positives are needed" and I'm ok with this thread.____
> >
> remains though due to scalability concerns that bunch of senior folks here
> raised already____
> >
> >              >      > From: Hannes Gredler <[email-masked]
> >              >     <mailto:[email-masked] <mailto:[email-masked]
> >>>
> >              >      > Cc: Robert Raszuk <[email-masked]
> >              >      > <[email-masked] <mailto:[email-masked]>
> >              >      > <[email-masked] <mailto:[email-masked]>
> >              >      > <[email-masked]
> >              >      > Just curious: Do you have an idea how to make
> >             short-lived LSPs
> >              >     compatible
> >              >      > | yes, default refresh is 900 for the default
> >             lifetime of 1200
> >              >     sec. Most
> >              >      > | If I send the LSP with the lifetime of 1 min,
> >             there will never
> >              >     be any
> >              >      > | the database. The only difference with the Pulse
> >             LSP is that it
> >              >     is not
> >              >      > | you can run anything over GRE, including IGPs,
> >             and you don't
> >              >     need TCP

---

From: Peter Psenak <[email-masked]>
Date: Thu, 2 Dec 2021 14:27:52 +0100

On 02/12/2021 14:19, Robert Raszuk wrote:
> I am asking as this is one of my objections. If this is fixed please 
> share details.

interested clients on the receiving router - e.g. BGP, TE, etc,.

Peter

> 
> Thx,
> R.
> 
> 
> 
> On Thu, Dec 2, 2021 at 2:03 PM Peter Psenak <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Tony,
> 
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     Tony –____
>      >
>      >     __ __
>      >
>      >     Inline.____
>      >
>      >     __ __
>      >
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>;
>     Hannes Gredler <[email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>; lsr
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>; Aijun
>     Wang <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]>>>; Robert Raszuk
>      >     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>; Shraddha Hegde
>      >     <[email-masked] <mailto:[email-masked]>
>      >     So you tell me I onver-interpreted as "between restarts" ;-)
>     OK, fine. Fair 'nuff. Maybe add one sentence clarification.____
>      >
>      >     */[LES:] Sure./*____
>      >
>      >     Otherwise yeah, I'd like the draft to add the "in case of
>     partition things may break but it's not much worse than before" ;-)
>     and "assumption is that the overlay will retry after dropping
>     session on negative so no positives are needed" and I'm ok with this
>     thread.____
>      >
>      >     my big gripe about "don't do it in main ISIS, take service
>     instance" remains though due to scalability concerns that bunch of
>     senior folks here raised already____
>      >
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:____
>      >
>      >         Tony –____
>      >
>      >         ____
>      >
>      >         ____
>      >
>     <mailto:[email-masked]>
>      >         <mailto:[email-masked] <mailto:[email-masked]>>>
>     <mailto:[email-masked]>
>     Hannes Gredler <[email-masked] <mailto:[email-masked]>
>      >         <mailto:[email-masked] <mailto:[email-masked]>>>;
>     lsr <[email-masked] <mailto:[email-masked]>
>      >         <mailto:[email-masked] <mailto:[email-masked]>>>; Aijun
>     Wang <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]>>>; Robert Raszuk
>      >         <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>; Shraddha Hegde
>      >         <[email-masked] <mailto:[email-masked]>
>     seqnr#
>     <[email-masked] <mailto:[email-masked]>
>     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?
>      >
>      >              > -- tony
>      >              > On Tue, Nov 30, 2021 at 11:19 PM Les Ginsberg
>     (ginsberg)
>      >              > <ginsberg=[email-masked]
>     <mailto:[email-masked]>>
>      >              > <mailto:[email-masked]
>     <mailto:[email-masked]>>>> wrote:
>      >              >
>      >              >     Hannes -
>      >              >
>      >              >     Please see
>      >              >
>      >
>      >              >     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-masked]
>     <mailto:[email-masked]>
>      >             <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>
>      >             <mailto:[email-masked] <mailto:[email-masked]>>>>
>      >              >      > Sent: Tuesday, November 30, 2021 11:22 AM
>      >              >      > To: Peter Psenak (ppsenak)
>     <[email-masked] <mailto:[email-masked]>
>      >             <mailto:[email-masked] <mailto:[email-masked]>>
>      >              >     <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>>
>      >              >      > Cc: Robert Raszuk <[email-masked]
>     <mailto:[email-masked]>
>      >             <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>
>      >             <mailto:[email-masked] <mailto:[email-masked]>>>>;
>      >              >     Les Ginsberg (ginsberg)
>      >              >      > <[email-masked]
>      >             <mailto:[email-masked]
>     <mailto:[email-masked]>>>>;
>      >             Aijun Wang
>      >              >     <[email-masked]
>     <mailto:[email-masked]>>
>     <mailto:[email-masked]>>>>; lsr
>      >              >      > <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >             <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>; Tony Li
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >              >     <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>>;
>      >             Shraddha Hegde
>      >              >      > <[email-masked]
>      >             <mailto:[email-masked]
>     <mailto:[email-masked]>> <mailto:[email-masked]
>      >             <mailto:[email-masked]
>     <mailto:[email-masked]>>>>
>      >              >      > 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.
>      >              >      > | >
>      >              >
>      >
>      >              >      > 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-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked]
>     <mailto:[email-masked]>
>      >             <mailto:[email-masked] <mailto:[email-masked]>>>
>      >              > https://www.ietf.org/mailman/listinfo/lsr
>      >              > ____
>      >
>

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 2 Dec 2021 15:58:24 +0100

On Thu, Dec 2, 2021 at 2:03 PM Peter Psenak <[email-masked]> wrote:

> reachable.

we disagree based on my experience whereas the "went down" is only
"IGP does not see it anymore" in the draft definition here unless we want
to start to write in LSR draft that encompass multi-protocol router
requirements and
system design.

> The purpose of the pulse is not to defeat the purpose of the

so if we intend to inform the service source that "IGP thinks it cannot
reach an address anymore through
an ABR (because other ABRs may still reach it [solving that preconditions
AFAIS re-invention of add-path in IGP on leaking and/or lots interesting
paxos-direction protocol work] but maybe other protocols/aggregates can
still reach it)"
so the source as you say "may do something" then it slowly deems to me
that we are not standardizing anything but some "rough hunch of a rumour"
I would never advise a customer to act upon given how very expensive
a false positive on service is including e.g. BGP re-sync or tunnel
tear-downs.

> we can limit the pulse notification to host prefixes. That should

I would prefer not to add hidden /32 semantics to protocol features since
the more things become "special" and "asymmetric" the harder it's to
explain how things work & why they don't work when deployed as expected.

-- tony

---

From: Peter Psenak <[email-masked]>
Date: Thu, 2 Dec 2021 16:30:33 +0100

Tony,

> to start to write in LSR draft that encompass multi-protocol router 

for any practical purposes when the IGP can not see a host route in its 
source area it is considered down. That's what happens today without 
summarization.

> a false positive on service is including e.g. BGP re-sync or tunnel 

we are going to use the same "rumour" that is used today when the /32 is 
lost on ABR in the source area. The only difference is that instead of 
stopping the advertisement of the previously advertised /32, we generate 
a pulse and keep advertising the summary.

thanks,
Peter
> I would prefer not to add hidden /32 semantics to protocol features 
> since the more things become "special" and "asymmetric" the harder it's 
> to explain how things work & why they don't work when deployed as expected.
> 
> -- tony
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 2 Dec 2021 18:43:37 +0100

> a pulse and keep advertising the summary.

That is not the only difference. There are more significant differences
which were already discussed so no need to repeat them again.

Thx,
R.