Shraddha, Robert and all,
Regarding Robert's question:
I wonder if multi-hop IP BFD session with addresses used as /32 (or /128)
prefixes serving as Nose SIDs of R8 and R7 respectively could be used as such a
trigger by R7? Such a session would not respond to link failures, and I find it
problematic to imagine a scenario when it would be kept UP in the case of a
real node failure.
Of course such a session would have to be slow enough not to react to link
failures. But it still couks be much faster than IGP conversion IMHO.
My 2c,
Sasha
Such
Get Outlook for Android<https://aka.ms/ghei36>
________________________________
From: spring <[email protected]> on behalf of Robert Raszuk
<[email protected]>
Sent: Friday, November 22, 2019, 11:22
To: Shraddha Hegde
Cc: [email protected]; [email protected]
Subject: Re: [spring] Draft for Node protection of intermediate nodes in SR
Paths
Hi Shraddha,
I have one question to the document.
As you know the critical element for the effective protection of any scheme is
the failure detection. On that your draft seems to have just one little
paragraph:
Note that R7 activates the node-protecting backup path when it
detects that the link to R8 has failed. R7 does not know that node
R8 has actually failed. However, the node-protecting backup path is
computed assuming that the failure of the link to R8 implies that R8
has failed.
Well IMO this is not enough. Specifically there can be a lot of types of node
failure when link is still up. Moreover there can be even running BFD across
the link just fine when say fabric failure occurs at R8.
While this is not solely issue with this draft, it is our common IETF failure
to provide correct means of detecting end to end path or fragments of path
failures (I am specifically not calling them segment here :).
For example I propose that to effectively detect R8 failure as node failure
which is the topic of your proposal a mechanism is clearly defined and includes
bi-dir data plane probes send between R7-R9, R3-R7, R4-R7, R4-R9, R3-R9
Many thx,
Robert.
On Fri, Nov 22, 2019 at 4:38 AM Shraddha Hegde
<[email protected]<mailto:[email protected]>>
wrote:
WG,
This is the draft I pointed out that talks about solutions for providing
node-protection.
It covers Anycast case as well as keeping forwarding plane longer.
https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-05<https://clicktime.symantec.com/375SW6TBGPi2mN7V9YeVWGg6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-hegde-spring-node-protection-for-sr-te-paths-05>
Review and comments solicited.
Rgds
Shraddha
_______________________________________________
rtgwg mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/rtgwg<https://clicktime.symantec.com/35M9j5zHTaSYRwVh5RP6xcB6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frtgwg>
___________________________________________________________________________
This e-mail message is intended for the recipient only and contains information
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received
this
transmission in error, please inform us by e-mail, phone or fax, and then
delete the original
and all copies thereof.
___________________________________________________________________________
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
