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-ali-spring-bfd-sr-policy-02 Cheers, R. On Mon, Dec 2, 2019 at 11:06 AM Andrew Alston < [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]> > *Sent:* Monday, 2 December 2019 12:50 > *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 > > > > On Mon, Dec 2, 2019 at 10:28 AM Andrew Alston < > [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
