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

[Andrew Alston]

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 <rob...@raszuk.net>
Sent: Monday, 2 December 2019 13:14
To: Andrew Alston <andrew.als...@liquidtelecom.com>
Cc: Shraddha Hegde <shraddha=40juniper....@dmarc.ietf.org>; Alexander 
Vainshtein <alexander.vainsht...@ecitele.com>; spr...@ietf.org; 
rtg-bfd@ietf.org; rt...@ietf.org
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 
<andrew.als...@liquidtelecom.com<mailto:andrew.als...@liquidtelecom.com>> 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 <rob...@raszuk.net<mailto:rob...@raszuk.net>>
Sent: Monday, 2 December 2019 12:50
To: Andrew Alston 
<andrew.als...@liquidtelecom.com<mailto:andrew.als...@liquidtelecom.com>>
Cc: Shraddha Hegde 
<shraddha=40juniper....@dmarc.ietf.org<mailto:40juniper....@dmarc.ietf.org>>; 
Alexander Vainshtein 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>; 
spr...@ietf.org<mailto:spr...@ietf.org>; 
rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>; rt...@ietf.org<mailto:rt...@ietf.org>
Subject: Re: [spring] Draft for Node protection of intermediate nodes in SR 
Paths

On Mon, Dec 2, 2019 at 10:28 AM Andrew Alston 
<andrew.als...@liquidtelecom.com<mailto:andrew.als...@liquidtelecom.com>> 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.