Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

[Tony Przygienda <[e-mail]>]

I know it's not fashionable (yet) but put multipoint BFD on BIER & run 2
subdomains and you got 10K. Add subdomains to taste which will also allow
to partition it across chips easily. Yepp, needs silicon that will sustain
reasonable rates but you have a pretty good darn' solution. IGP gives you
reachability for BIER already, you got minimal replication and you can tune
your timers to heart's delight.

Sticking stuff in IGP (to second Tony #1) is very satisfying, especially
since some of that could work some time @ no load on IGP. All those "let's
add a million things to IGP" only catches you when you realize in serious
outage your IGP is busy figuring out/flooding junk rather than getting you
basic connectivity. Yes, good implementation technique and careful design
of protocol can help (e.g. take ISIS extensions that allow you for a large
LSP space where you know what priority things are that need to go out/come
in/compute, here is sympathize with the new idea of separate instance for
"junk hauling" BTW ;-) but mashing overlay into underlay of your most time
sensitive and delicate piece of network control to use it as overlay
signalling protocol does not have a promising history. Confounding the
whole thing on top with adding a route type as signalling means is a bit
injury on top of insult or vice versa

-- tony

On Tue, Mar 9, 2021 at 12:03 PM Robert Raszuk <[e-mail]> wrote:

> Hey Peter,
>
> Well ok so let's forget about LDP - cool !
>
> So IGP sends summary around and that is all what is needed.
>
> So the question why not propage information that PE went down in service
> signalling - today mainly BGP.
>
> >   And forget BFD, does not scale with 10k PEs.
>
> You missed the point. No one is proposing full mesh of BFD sessions
> between all PEs. I hope so at least.
>
> PE is connected to RRs so you need as many BFD sessions as RR to PE BGP
> sessions. Once that session is brought down RR has all it needs to trigger
> a message (withdraw or implicit withdraw) to remove the broken service
> routes in a scalable way.
>
> Thx,
> R.
>
> PS. Yes we still need to start support signalling of unreachability in BGP
> itself when BGP is used for underlay but this is a bit different use case
> and outside of scope of LSR
>
>
> On Tue, Mar 9, 2021 at 11:55 AM Peter Psenak <[e-mail]> wrote:
>
>> Robert,
>>
>> On 09/03/2021 11:47, Robert Raszuk wrote:
>> >  > You’re trying to fix a problem in the overlay by morphing the
>> > underlay.  How can that seem like a good idea?
>> >
>> > I think this really nails this discussion.
>> >
>> > We have discussed this before and while the concept of signalling
>> > unreachability does seem useful such signalling should be done where it
>> > belongs.
>> >
>> > Here clearly we are talking about faster connectivity restoration for
>> > overlay services so it naturally belongs in overlay.
>> >
>> > It could be a bit misleading as this is today underlay which propagates
>> > reachability of PEs and overlay relies on it. And to scale,
>> > summarization is used hence in the underlay, failing remote PEs remain
>> > reachable. That however in spite of many efforts in lots of networks
>> are
>> > really not the practical problem as those networks still relay on exact
>> > match of IGP to LDP FEC when MPLS is used. So removal of /32 can and
>> > does happen.
>>
>> think SRv6, forget /32 or /128 removal. Think summarization.
>>
>> I'm not necessary advocating the solution proposed in this particular
>> draft, but the problem is valid. We need fast detection of the PE loss.
>>
>> And forget BFD, does not scale with 10k PEs.
>>
>> thanks,
>> Peter
>>
>>
>>
>> >
>> > In the same time BGP can pretty quickly (milliseconds) remove affected
>> > service routes (or rather paths) hence connectivity can be restored to
>> > redundantly connected endpoints in sub second. Such removal can be in a
>> > form of atomic withdraw (or readvertisement), removal of recursive
>> > routes (next hop going down) or withdraw of few RD/64 prefixes.
>> >
>> > I am not convinced and I have not seen any evidence that if we put this
>> > into IGP it will be any faster across areas or domains (case of
>> > redistribution over ASBRs to and from IGP to BGP). One thing for sure -
>> > it will be much more complex to troubleshoot.
>> >
>> > Thx,
>> > R.
>> >
>> > On Tue, Mar 9, 2021 at 5:39 AM Tony Li <[e-mail]
>> > <mailto:[e-mail]>> wrote:
>> >
>> >
>> >     Hi Gyan,
>> >
>> >      >     Gyan> In previous threads BFD multi hop has been mentioned to
>> >     track IGP liveliness but that gets way overly complicated especially
>> >     with large domains and not viable.
>> >
>> >
>> >     This is not tracking IGP liveness, this is to track BGP endpoint
>> >     liveness.
>> >
>> >     Here in 2021, we seem to have (finally) discovered that we can
>> >     automate our management plane. This ameliorates a great deal of
>> >     complexity.
>> >
>> >
>> >      >     Gyan> As we are trying to signal the IGP to trigger the
>> >     control plane convergence, the flooding machinery in the IGP already
>> >     exists well as the prefix originator sub TLV from the link or node
>> >     failure.  IGP seems to be the perfect mechanism for the control
>> >     plane signaling switchover.
>> >
>> >
>> >     You’re trying to fix a problem in the overlay by morphing the
>> >     underlay.  How can that seem like a good idea?
>> >
>> >
>> >      >       Gyan>As I mentioned advertising flooding of the longer
>> >     prefix defeats the purpose of summarization.
>> >
>> >
>> >     PUA also defeats summarization.  If you really insist on faster
>> >     convergence and not building a sufficiently redundant topology, then
>> >     yes, your area will partition and you will have to pay the price of
>> >     additional state for your longer prefixes.
>> >
>> >
>> >      > In order to do what you are stating you have to remove the
>> >     summarization and go back to domain wide flooding
>> >
>> >
>> >     No, I’m suggesting you maintain the summary and ALSO advertise the
>> >     longer prefix that you feel is essential to reroute immediately.
>> >
>> >
>> >      > which completely defeats the goal of the draft which is to make
>> >     host route summarization viable for operators.  We know the prefix
>> >     that went down and that is why with the PUA negative advertisement
>> >     we can easily flood a null0 to block the control plane from
>> >     installing the route.
>> >
>> >
>> >     So you can also advertise the more specific from the connected ABR…
>> >
>> >
>> >      > We don’t have any prior knowledge of the alternate for the egress
>> >     PE bgp next hop attribute for the customer VPN overlay.  So the only
>> >     way to accomplish what you are asking is not do any summarization
>> >     and flood al host routes.  Of course  as I stated defeats the
>> >     purpose of the draft.
>> >
>> >
>> >     Please read again.
>> >
>> >     Tony
>> >
>> >     _______________________________________________
>> >     Lsr mailing list
>> >     [e-mail] <mailto:[e-mail]>
>> >     https://www.ietf.org/mailman/listinfo/lsr
>> >
>>
>> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>