Hi Shraddha The PUA draft is detecting the BGP NH liveliness based on the PUA protection mechanism for immediate control plane convergence immediately on alternative next - next hop, analogous to FRR link and node protection but without the complexity.
I agree the egress protection RFC 8679 mechanism using RSVP-TE Egress protection extension RFC 8400 can provide fast FRR link and mode protection mechanism for global repair but at a operational cost of RSVP-TE FRR protection schemes which may or may not be deployed by the operator. The PUA and event notification drafts provide a simple IGP extension based mechanism to provide the same and can be utilized in scenarios where RSVP-TE may not be deployed or desirable. I agree in most cases large aggregation domains converged transport networks with MPLS-TP transport core that RSVP-TE is deployed. PUA provides next hop liveliness detection and protection that can be applied to SRv6 SR-TE policy as well, similar to what S-BFD SR-TE policy liveliness, this PUA draft is providing similar via next hop liveliness in protecting the egress PE SRv6 SR-TE policy. Kind Regards Gyan On Wed, Nov 24, 2021 at 11:10 PM Shraddha Hegde <[email protected]> wrote: > 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 > > > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
