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.
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 <shraddha= > [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 <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] <[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 > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-chen-rtgwg-srv6-midpoint-protection-05__;!!NEt6yMaO-gk!SSAVRO90Q62ieX5DTTgZBW4FKiC_YHXU9biL8pK-jEOUv7jmUHGUaHAt89kXBaSb$> > .) 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
