Hi, Robert: Aijun Wang China Telecom
> On Nov 27, 2021, at 18:19, Robert Raszuk <[email protected]> wrote: > > > > All P routers (except very few exceptions) run the very same software as PEs. > So it can easily build a session to RR to learn the routes. [WAJ] if we agree all P routers and PE routers expect to receive such information, is there any advantage to use BGP to transfer information? Considering there are some unsolved questions that we mentioned for your proposal in another thread? > > Thx, > R. > >> On Sat, Nov 27, 2021 at 4:13 AM Huzhibo >> <[email protected]> wrote: >> Hi Robert: >> >> >> >> There may be other egress protection solution. However, the PLR is a P node >> and cannot sense BGP information. The PLR needs to establish a master/backup >> PE relationship. In some implementations as I know, It was manually >> specified in some way. Dynamic and automated I'm not sure if there's a >> available and safe solution. >> >> >> >> Regards >> >> >> >> Zhibo >> >> >> >> 发件人: Lsr [mailto:[email protected]] 代表 Robert Raszuk >> 发送时间: 2021年11月26日 17:00 >> 收件人: Huzhibo <[email protected]> >> 抄送: Les Ginsberg (ginsberg) <[email protected]>; Gyan Mishra >> <[email protected]>; Acee Lindem (acee) <[email protected]>; Christian >> Hopps <[email protected]>; Aijun Wang <[email protected]>; Tony Li >> <[email protected]>; lsr <[email protected]>; Shraddha Hegde >> <[email protected]>; Tony Przygienda >> <[email protected]> >> 主题: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting >> Minutes >> >> >> >> >> >> Huzhibo, >> >> >> >> > specifying the master/backup relationship of egress protection is complex >> >> >> >> Sure is - but there is absolutely no requirement to do it. BGP already >> carries all information needed to instantiate such protection. It is >> therefore all dynamic and automated. >> >> >> >> As said cost is extra LFIB space on the PEs acting as a backup. With per VRF >> or per CE label allocation that is not big deal. With per prefix label >> allocation yes that can be a resource constraint to consider. >> >> >> >> So if we are discussing drawbacks of any proposal let's just use correct >> arguments :) >> >> >> >> Cheers, >> >> R. >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Fri, Nov 26, 2021 at 9:09 AM Huzhibo >> <[email protected]> wrote: >> >> Hi, Shraddha: >> >> >> >> If there are a large number of CE-to-PE mix-homing scenarios, >> specifying the master/backup relationship of egress protection is complex, >> which greatly increases deployment complexity. Therefore, local protection >> is not applicable to all scenarios. In addition, local protection also >> generates suboptimal paths. Therefore, even if local protection is deployed, >> speeding up ingress PE convergence is useful. >> >> >> >> Regards >> >> >> >> Zhibo >> >> >> >> From: Lsr [mailto:[email protected]] On Behalf Of Shraddha Hegde >> Sent: Friday, November 26, 2021 12:49 PM >> To: Huzhibo <[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 >> >> >> >> Huzhibo, >> >> >> >> Local protection is always executed on the node where failure occurs (for >> link protection) and the previous node >> >> (for node failure). 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 >> >> 1. Use anycast SID as mid-points for redundancy >> >> 2. Mid-point failure local protection by looking up next sid (This is >> probably the one you pointed out) >> >> 3. 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 > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
