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

[Andrew Alston <[e-mail]>]

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 <[e-mail]>
Sent: Monday, 2 December 2019 13:14
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


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 <[e-mail]<mailto:[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]<mailto:[e-mail]>>
Sent: Monday, 2 December 2019 12:50
To: Andrew Alston <[e-mail]<mailto:[e-mail]>>
Cc: Shraddha Hegde <shraddha=[e-mail]<mailto:[e-mail]>>; Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[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.