Hi, Robert: Aijun Wang China Telecom
> On Nov 24, 2021, at 18:12, Robert Raszuk <rob...@raszuk.net> wrote: > > > Aijun, > > Nothing Shraddha is describing is about protecting intermediate hops. > > She illustrated different solutions for egress protection of PEs. > > It has some cost and some deployment limitations but it is an option to > consider. [WAJ] Yes. What I want to express is that there are situations that Egress Protection only is not enough, which is asking by Shraddha. > > Thx, > R. > >> On Wed, Nov 24, 2021 at 6:44 AM Aijun Wang <wangai...@tsinghua.org.cn> wrote: >> 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: lsr-boun...@ietf.org <lsr-boun...@ietf.org> On Behalf Of Shraddha Hegde >> Sent: Wednesday, November 24, 2021 1:20 PM >> To: Tony Li <tony...@tony.li>; Aijun Wang <wangai...@tsinghua.org.cn> >> Cc: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Gyan Mishra >> <hayabusa...@gmail.com>; Christian Hopps <cho...@chopps.org>; lsr >> <lsr@ietf.org>; Acee Lindem (acee) <a...@cisco.com>; Tony Przygienda >> <tonysi...@gmail.com> >> 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 <lsr-boun...@ietf.org> On Behalf Of Tony Li >> Sent: Tuesday, November 23, 2021 10:22 PM >> To: Aijun Wang <wangai...@tsinghua.org.cn> >> Cc: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Gyan Mishra >> <hayabusa...@gmail.com>; Christian Hopps <cho...@chopps.org>; lsr >> <lsr@ietf.org>; Acee Lindem (acee) <a...@cisco.com>; Tony Przygienda >> <tonysi...@gmail.com> >> 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 >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
