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:[email protected]] On Behalf Of Joel M. Halpern
Sent: Monday, August 3, 2020 7:51 AM
To: [email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
