Re: [spring] Spring protection

Hi Joel and all:

    I think node protected is used when the SLA of a path cannot be quickly repaired. E2E detection cannot be deployed in some scenarios. As a result, the faulty path cannot be repaired at the headend. 
    To prevent SR policy from bypassing Service Sid, if the Per Sid forwarding state is not introduced on other nodes, the advertise Sid Not Bypass Flag is useless. Therefore, extending the Not Bypass Flag in the SRH Flag may be an effective method. The following document is trying to solve such problem.https://datatracker.ietf.org/doc/draft-li-rtgwg-enhanced-ti-lfa/?include_text=1

Thanks

Zhibo

-----Original Message-----
From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Joel M. Halpern
Sent: Monday, August 3, 2020 7:51 AM
To: spring@ietf.org
Subject: [spring] Spring protection - determining applicability

(WG Chair hat Off, this is merely a note from a slightly confused WG
participant.)

I have been reading the various repair drafts, and the various networks programming and service programming draft, and I am trying to figure out one aspect of the combination.

How does a node that is doing some form of bypass (suppose, for simplicity, it is Node N2 deciding to bypass the next SID for a failed node N3) know that it is safe to do so?

If the path was just for TE, then it is "safe" if the new path meets the TE criteria.  or maybe it is safe if it is even close, as long as it is not used for too long.

But what if the node were a Firewall, included to meet legal requirements?
Or was some other necessary programmatic transform (wince we are deliberately vague about what nodes can do when asked suitably.)

Is there some "can be bypassed" indication in the routing advertisements that I missed?

Thank you,
Yours,
Joel

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Spring protection - determining applicability