Hi,Shraddha: Aijun Wang China Telecom
> On Nov 26, 2021, at 12:49, Shraddha Hegde <[email protected]> wrote: > > > Huzhibo, > > Local protection is always executed on the node where failure occurs (for > link protection) and the previous node > (for node failure). [WAJ] For SRv6 policy based tunnel, the previous node may not be the neighbor node. It may locate in other area. > You don’t really require the failure event to propagate to another domain to > trigger local protection. > > Rgds > Shraddha > > > Juniper Business Use Only > From: Huzhibo <[email protected]> > Sent: Thursday, November 25, 2021 3:04 PM > To: Shraddha Hegde <[email protected]>; Aijun Wang > <[email protected]>; 'Tony Li' <[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, Shraddha: > > If you punch a hole in the summary, the other area nodes come to know about > the mid-point failure.---> Yes, you're right. Once any node knows about the > mid-point failure，It can execution local protection by looking up next sid to > fix SRv6 Policy reachability. > > Thanks > > Zhibo > > > From: Lsr [mailto:[email protected]] On Behalf Of Shraddha Hegde > Sent: Thursday, November 25, 2021 12:11 PM > To: Aijun Wang <[email protected]>; 'Tony Li' <[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 > > Aijun, > > There are multiple possible solutions for the SR-Policy mid-point failure > scenario > Use anycast SID as mid-points for redundancy > Mid-point failure local protection by looking up next sid (This is probably > the one you pointed out) > E2E S-BFD for SR-Policy path liveness detection > > If you punch a hole in the summary, the other area nodes come to know about > the mid-point failure > and remove the failed node reachability. It is not clear how that is solving > the SR-Policy liveness problem. > > Rgds > Shraddha > > > Juniper Business Use Only > From: Aijun Wang <[email protected]> > Sent: Wednesday, November 24, 2021 11:14 AM > To: Shraddha Hegde <[email protected]>; 'Tony Li' <[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, Shraddha: > > If the traffic is steered via the SRv6 policy, the intermediate points should > also be protected. There are already one draft to propose the solution( > please refer to > https://datatracker.ietf.org/doc/html/draft-chen-rtgwg-srv6-midpoint-protection-05.) > In such situation, if the intermediate points located in different areas, > how then know the liveness of each other if ABR has the summary address > advertised? We will not consider to configure BFD on every intermediate > points. > > > Best Regards > > Aijun Wang > China Telecom > > From: [email protected] <[email protected]> On Behalf Of Shraddha Hegde > Sent: Wednesday, November 24, 2021 1:20 PM > To: Tony Li <[email protected]>; 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 > > 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 > 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
