Re: [spring] Draft for Node protection of intermediate nodes in SR Paths

[Robert Raszuk <[e-mail]>]

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 <
[e-mail]> 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 <[e-mail]>
> *Sent:* Monday, 2 December 2019 12:50
> *To:* Andrew Alston <[e-mail]>
> *Cc:* Shraddha Hegde <shraddha=[e-mail]>; Alexander
> Vainshtein <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]
> *Subject:* Re: [spring] Draft for Node protection of intermediate nodes
> in SR Paths
>
>
>
> On Mon, Dec 2, 2019 at 10:28 AM Andrew Alston <
> [e-mail]> 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.
>
>