Peter, > it requires SID allocation to be synchronized between multiple egress PEs.
That is not correct. The concept Shraddha is describing does not require any synchronization of either VPN demux label or SIDs. In an essence you create based on regular service routing propagation a shadow FIB/LFIB/SID-FIB on the backup PEs. The PLR uses different label/SID to steer traffic to such shadow FIB/LFIB/SID-FIB. Yes it costs some resources but other then that it is a viable option. I was thinking if I should bring it to this thread however it is a different category of solution hence and pretty well known hence did not mentioned it. Cheers, R. On Wed, Nov 24, 2021 at 10:23 AM Peter Psenak <ppsenak= [email protected]> wrote: > Shraddha, > > On 24/11/2021 06:19, Shraddha Hegde wrote: > > WG, > > > > MPLS egress protection framework RFC 8679 provides a mechanism to > > locally protect the traffic during > > > > PE failures. The concepts can be applied to SRv6 as well. This mechanism > > is much more efficient and quick because it locally provides fast > protection > > it requires SID allocation to be synchronized between multiple egress > PEs. With per CE SID allocation and multiple next-hops on each PE, the > number of SIDs become large and keeping them in sync is challenging. > > Using anycast SID approach, you are loosing overlay (BGP) ECMP performed > at the ingress and replace it with underlay (IGP) ECMP towards the > egress. This may prevent BGP to load balance across multiple PEs or even > pick one as a preferred one. > > So while it is a alternative, it has its drawbacks. We are trying to > provide a solution which would not pose any extra requirement to SID > allocation, nor affect BGP in any way. > > thanks, > Peter > > > > > > And switchover to the other PE. > > > > If you compare this to the mechanisms being discussed in this thread > > where the failure information is being > > > > propagated by the egress PE to ABR and then ABR to the ingress, the > > failover is going to be much slower. > > > > The egress protection technology does not flood any information outside > > of the domain and hence does not > > > > affect the IGP scale. > > > > This is a valid alternate solution to solve the problem at hand IMO. > > > > I would be interested to see if people have use cases where egress > > protection can’t be applied. > > > > Rgds > > > > Shraddha > > > > Juniper Business Use Only > > > > *From:* Lsr <[email protected]> *On Behalf Of *Tony Li > > *Sent:* Tuesday, November 23, 2021 10:22 PM > > *To:* Aijun Wang <[email protected]> > > *Cc:* Les Ginsberg (ginsberg) <[email protected]>; Gyan Mishra > > <[email protected]>; Christian Hopps <[email protected]>; lsr > > <[email protected]>; Acee Lindem (acee) <[email protected]>; Tony Przygienda > > <[email protected]> > > *Subject:* Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF > > 112 LSR Meeting Minutes > > > > *[External Email. Be cautious of content]* > > > > Hi Aijun, > > > > I object to adding negative liveness to the LSDB because of the > > scale and because it adds scale during failures. > > > > */[WAJ] If we have no such mechanism, operator should either > > advertise the host routes across areas(which has scale problem), or > > lose the fast convergences for some overlay services(which defeat > > the user experiences)./* > > > > */Within the real network, there is very rare chance for the massive > > failure. And even such thing happen accidently, the information > > about node liveness is countable, is there any router can’t process > > such information?/* > > > > */The received unreachable information does not trigger the SPF > > calculation. Will they influence intensively the performance of the > > router?/* > > > > If the scale is equal, then I would prefer to see flooding positive > > information rather than negative information. Operationally this is > > key: if there is a failure and positive information doesn’t propagate, > > then it’s a bug that will be found in due course and the operator can > > react outside of a failure scenario. > > > > Having a scale failure on top of a topology failure is a far more > > painful scenario. > > > > The odds of a mass failure may be low. The fact of the matter is that > > they still happen. It is our job to ensure that the IGP performs well > > when it does. > > > > Increasing the size of the LSDB always affects performance. It slows > > flooding. Some nodes may not realize that SPF is not needed. When LSP > > fragments are rearranged, inferring that SPF is not necessary is > > non-trivial. Impacting router and network performance is a given. > > > > My understanding is that N node failures would result in O(N) bytes > > added to the LSDB. If someone has a way to compress that > > information to O(1), I (and Claude Shannon) would be interested. > > > > */[WAJ] Do you have other determined solutions except the PUB/SUB > > mechanism that does not exist in current IGP?/* > > > > None of the mechanisms being discussed currently exist. > > > > I have no objections to Robert’s BGP propagation ideas if that’s > workable. > > > > This is simply not the IGP’s job and the IGP is not a dump truck. > > > > Tony > > > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
