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

[Peter Psenak <[e-mail]>]

Hi Robert,

On 09/03/2021 12:02, Robert Raszuk 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.

because BGP signalling is prefix based and as a result slow.

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

that can be still too many.
In addition you may have a hierarchical RR, which would still involve 
BGP signalling.

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.

that is the whole point, you need something that is prefix independent.

thanks,
Peter

> 
> 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] 
> <mailto:[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]>
>      > <mailto:[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]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      > https://www.ietf.org/mailman/listinfo/lsr
>      >
>