RFC 8679 does not require RSVP-TE to work. Best, R.
On Thu, Nov 25, 2021 at 5:30 PM Gyan Mishra <[email protected]> wrote: > > 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 >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
