Understood as this egress protection framework applies to all current and future protocols, however if you are using RSVP-TE which in most cases you are today with converged transport aggregation domain then you would use the RFC 8400 extension.
Happy Thanksgiving!🦃🍽 Gyan On Thu, Nov 25, 2021 at 11:33 AM Robert Raszuk <[email protected]> wrote: > > 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 >> > -- <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
