Robert,
On 26/11/2021 17:47, Robert Raszuk wrote:
Peter,
As I told you many times I do see a need to signal summary member
liveness. Otherwise I would not be spending time here.
But what I am trying to discuss is the proposed mechanism of such
signalling and possible alternatives.
I suggested to you to do selective leaking. I do not recall seeing any
answer from you on that. Les acked you did not. Maybe you want to first
discuss internally which is fine.
So back to the topic.
How about you just leak those PEs which went down with a flag "DOWN" and
when it comes up you clear that flag. That way the IGP carries the
liveness in exactly the same way as today via leaking everything.
that's similar what the PUA draft proposes. The disadvantages is that
you need to flood twice:
a) prefix DOWN itself
b) clean the DOWN prefixes as you can not keep them around forever.
and you add to the existing LSDB, which goes against the summarization
itself.
Pulse cleans up itself without any additional flooding, that's the whole
idea of it. It also is not part of the LSDB that IGP uses for
computation, so it does not affect the scale.
However you at least is going to be leaking subset not everything. And
this is not going to be ephemeral but permanent. Maybe when PE is back
stable after 12h or any other long timer you stop leaking.
see above why the pulse.
thanks,
Peter
See it is very hard to support a proposal when you - someone who wrote a
prototype for it - can not answer basic question on how will it work
with just encapsulation. Yet you use p2p tunnel as example on how this
is useful. Sure tunnel will go down and will not come up till remote PE
is back in business. But with just encap (say mGRE) this is no longer
possible as the interface there is p2mp so it can not go down if even
one remote PE is still up.
Thx,
R.
On Fri, Nov 26, 2021 at 5:36 PM Peter Psenak <ppse...@cisco.com
<mailto:ppse...@cisco.com>> wrote:
Robert,
On 26/11/2021 17:18, Robert Raszuk wrote:
> Peter,
>
> Technically I see no justification to run any service within your
own
> domian over IPSec.
tell people that are doing so, not me.
>
> In those cases simple IP encapsulation works fine.
>
> So let's zoom on this scenario ... Your PEs communicate over IP
> encapsulation which does not require any connection establishment.
it's tunneling and there can be L3 or L2 client traffic being sent over
these tunnels. Having a fast tunnel end-pointy down notification
(without the need to run multi-hop BFD) helps the overlay network
convergence. Same as with BGP.
Just accept the fact that other overlay protocols exists out there and
are actively being used. If you are not willing to accept tt, no point
discussing further.
thanks,
Peter
>
> They start to exchange packets using summary routes.
>
> PE1 goes down and PULSE reaches remote PE2 - then what exactly is to
> happen there ?
>
> In RIB you still have valid summary route. You do not have in RIB
/32
> for remote PE1. PULSE comes and what ?
>
> If you run BGP it could trigger next hop invalidation and best path
> re-run. But there is no BGP as you say.
>
> Depending on how you implement encapsulation you could remove
such encap
> rewrite from FIB, but for how long ? And what will tell you that the
> remote PE is up again ?
>
> All in all for PULSE to directly affect the data plane I think
lot's of
> new code needs to be written, tested and deployed. Leave alone
aspect of
> network wide flooding of those PULSEs.
>
> Many thx,
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Nov 26, 2021 at 4:38 PM Peter Psenak <ppse...@cisco.com
<mailto:ppse...@cisco.com>
> <mailto:ppse...@cisco.com <mailto:ppse...@cisco.com>>> wrote:
>
> Robert,
>
> On 26/11/2021 15:06, Robert Raszuk wrote:
> > Peter,
> >
> > again, if you use option 2. There are way too many
networks
> without it.
> >
> >
> > There is even more networks without PUA/PULSE today.
Should that
> be a
> > factor ?
>
> the solution should not depend on any particular deployment
of the
> overlay protocol.
>
> >
> > In summary, we need something that works independent
of the
> BGP design
> > and also works outside of BGP.
> >
> >
> > Really ? Is that the requirement that the solution
provided MUST
> not use
> > BGP ?
>
> for me the solution ideally should work for with any overlay
protocol.
>
> >
> > Please kindly describe a full practical deployment
scenario where
> PULSE
> > helps when BGP is not used at all in the network for
distributing
> > service reachability.
>
> I have explained that several times to you. There are SP networks
> running the services on top of p2p IP sec tunnels for
example, with
> no BGP.
>
> >
> > OSPF and ISIS are *link state* protocols. You are asking to
> extend them
> > to carry *node state* now. Specifically just to carry the
UP -> DOWN
> > transitions of a node state and moreover in an ephemeral
fashion.
>
> no, I'm only talking about the prefix unrechability.
Something that
> link
> state protocols advertise happily today.
>
> thanks,
> Peter
>
>
> >
> > Thx,
> > R,
>
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
