Thanks, Some how I had missed these drafts β I will go through in further detail and then potentially comment more. My bad for missing them and appreciate the pointers.
Thanks Andrew From: Robert Raszuk <[email protected]> Sent: Monday, 2 December 2019 13:14 To: Andrew Alston <[email protected]> Cc: Shraddha Hegde <[email protected]>; Alexander Vainshtein <[email protected]>; [email protected]; [email protected]; [email protected] Subject: Re: [spring] Draft for Node protection of intermediate nodes in SR Paths I encourage you to read those two documents: https://tools.ietf.org/html/draft-akiya-bfd-seamless-sr-04<https://tools.ietf.org/html/draft-akiya-bfd-seamless-sr-04> https://tools.ietf.org/html/draft-ali-spring-bfd-sr-policy-02<https://tools.ietf.org/html/draft-ali-spring-bfd-sr-policy-02> Cheers, R. On Mon, Dec 2, 2019 at 11:06 AM Andrew Alston <[email protected]<mailto:[email protected]>> wrote: Robert β actually I disagree. Because to protect the paths you need the node protection on intermediate nodes due to lack of state β the headend has no way to actually protect an end to end path outside of S-BFD steered over the path to test end to end reachability and if you get an intermediate node-failure on the path you could run into a problem π As per draft-ietf-spring-segment-routing-policy-05 a path is valid when: It is empty Its weight is 0 Itβs headend is unable to perform path resolution for the first SID into one or more outgoing interface(s) and next-hop(s) The headend is unable to perform SID resolution for any non-first SID of type C through K into an MPLS label or an SRv6 SID The headend verification fails for any SID for which verification has been explicitly requested Effectively β as of right now β if you read that draft β there is no mechanism to verify path nodes if you are doing paths based on type A SIDβs β the only way right now to do that β is using S-BFD β however this draft if my understanding is correct β would allow for node protection that would in effect protect the paths injected. Thanks Andrew From: Robert Raszuk <[email protected]<mailto:[email protected]>> Sent: Monday, 2 December 2019 12:50 To: Andrew Alston <[email protected]<mailto:[email protected]>> Cc: Shraddha Hegde <[email protected]<mailto:[email protected]>>; Alexander Vainshtein <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [spring] Draft for Node protection of intermediate nodes in SR Paths On Mon, Dec 2, 2019 at 10:28 AM Andrew Alston <[email protected]<mailto:[email protected]>> wrote: Currently the biggest issue that I see with S-BFD based protection β which is something we use in production is as follows: Unless Iβm mistaken β there is absolutely no way to tie S-BFD based protection with BGP injected SR-TE pathing Well I am not sure what you call " BGP injected SR-TE pathing" but if you are looking for validation of BGP paths that has been supported by some vendors for a loooong time. Hint: you allocate different next hop for your SR-TE endpoints and voila. Btw - not an ietf topic, but an implementation request / vendor's feature. Besides, since you are talking about headend what you are describing is path protection ... this draft talks about node protection which is a completely different thing. Cheers, r.
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
