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

From: Shraddha Hegde <[email-masked]>
Date: Mon, 2 Dec 2019 04:17:50 +0000

Hi Robert,

Thanks for your review and comments.

The objective of this draft is to describe how PLR can compute a node-protecting  backup path for SR path.

> 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

How to find node failed or link failed is not in the scope of this document.
If an operator decides to enable node protection, then always node-protecting backup paths will be in-force irrespective of link failed or node-failed.
This draft inherits the LFA notion for link and node failure and addresses how this can be handled for SR Paths.

I do see that the text in the draft is not enough to clarify what’s in scope of this document and what is not.
I’ll add some text in next revision to clarify.
Thanks again for pointing it out.

Rgds
Shraddha

From: Robert Raszuk <[email-masked]>
Sent: Friday, November 22, 2019 2:53 PM
To: Shraddha Hegde <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: 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 <shraddha=[email-masked]..org<mailto:[email-masked]>> 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://urldefense.com/v3/__https:/tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-05__;!8WoA6RjC81c!UWVX5SKMz9p87V054empi1a3OtpES7fAr7m1ZwVd-DFqj3-c8iUFGuM4xK8n_DAR$>

Review and comments solicited.

Rgds
Shraddha

_______________________________________________
rtgwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtgwg<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/rtgwg__;!8WoA6RjC81c!UWVX5SKMz9p87V054empi1a3OtpES7fAr7m1ZwVd-DFqj3-c8iUFGuM4xNcLZr4T$>

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 2 Dec 2019 05:09:49 +0000

Robert/Sasha,

S-BFD based mechanism is  head-end triggered protection. It is not a local protection.
S-BFD mechanism is orthogonal to the mechanism described in this draft and an operator can
choose what kind of protection makes more sense to his/her network.

In many cases, node-protecting backup path will be different from link-protecting/SRLG protecting backup path.
If you really want to use link-protecting backup path when link fails and node protecting backup path when node fails,
You will have to download both link protecting and node-protecting backup paths in FIB and detect which
failure really happened and have the ability in hardware to use appropriate backup path. None of these
is in the scope of this document.

Rgds
Shraddha

From: Alexander Vainshtein <[email-masked]>
Sent: Saturday, November 23, 2019 8:15 PM
To: Robert Raszuk <[email-masked]>; Shraddha Hegde <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [spring] Draft for Node protection of intermediate nodes in SR Paths

Robert,
On the second thought, for the purpose of this draft (i.e. in the scope of SR) it is possible to implement your suggestion by running S-BFD sessions between R7 (as the initiator) and each other adjacency of R8  (acting as Reflectors) of a SR policy with list of two SIDs:
- protected adjacency between R7 and R8
- Node SID of the specific "other" adjacency  of R8.

If all these sessions fail, R7 can reliably consider R8 as failed.

I am not sure this would be much better than multi-hop IP BFD, and it looks much more complicated to me.

What do you think?

Get Outlook for Android<https://urldefense.com/v3/__https:/aka.ms/ghei36__;!8WoA6RjC81c!Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0VmgnYBhAbc$>

________________________________
From: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, November 23, 2019, 13:15
To: Robert Raszuk; Shraddha Hegde
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Draft for Node protection of intermediate nodes in SR Paths

Robert,
Lots of thanks for a prompt response.

I respectfully disagree with your statement that BFD implementation  is usually offloaded to the HW of the ingress line card.  I do not think this can wor for MH BFD sessions because the ingress and egress line cards are not known in advance and change with the routing changes
A good  multi-hop BFD implementation should be ready to overcome this.. There are many ways to achieve that. A naive implementation that runs in SW of the control card is also possible of course. And they would sensd and receive packets

My 2c.
Get Outlook for Android<https://urldefense.com/v3/__https:/aka.ms/ghei36__;!8WoA6RjC81c!Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0VmgnYBhAbc$>

________________________________
From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, November 23, 2019, 12:37
To: Alexander Vainshtein; Shraddha Hegde
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Draft for Node protection of intermediate nodes in SR Paths

Hi Sasha,

On the surface your suggestion may look cool - but if you zoom in - I do not think it will work in practice.

See - one of the biggest value of BFD is its offload to line card's hardware. And in most cases it is ingress line card to the box. So if you instruct such hardware to respond to SID address loopback you still did not gain much in terms of detection router's fabric failures, remote LC failure or control plane issues which could soon result in box failure. The catalogue of router failures is of course much more colorful.

If you ask BFD to be responded by RP/RE it no longer has the BFD advantage.

IMHO the best way to detect node failure is actually to send the probes *across* the node under test to its peers.

The way I would think of establishing such m-hop sessions would be fully automated with one knob per IGP adj. ex: "bfd detect-node-failure [max N]" where local BFD subsystem would create N sessions to IGP peers of the node we are to protect. LSDB has those peers so no new protocol extension is needed, perhaps even no new IETF draft is required :). N would be the limit of such sessions in case the node under protection has say 10s of peers. Default could be perhaps even 1.

Thx,
Robert.

On Sat, Nov 23, 2019 at 10:00 AM Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:
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://urldefense.com/v3/__https:/clicktime.symantec.com/3CfVQPtBYBAPbHUSngEVNQD6H2?u=https*3A*2F*2Faka.ms*2Fghei36__;JSUlJQ!8WoA6RjC81c!Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0Vmgujy50EN$>

________________________________
From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Friday, November 22, 2019, 11:22
To: Shraddha Hegde
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Draft for Node protection of intermediate nodes in SR Paths

Hi Shraddha,

   has failed.

Many thx,
Robert.

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://urldefense.com/v3/__https:/clicktime.symantec.com/375SW6TBGPi2mN7V9YeVWGg6H2?u=https*3A*2F*2Ftools.ietf.org*2Fhtml*2Fdraft-hegde-spring-node-protection-for-sr-te-paths-05__;JSUlJSU!8WoA6RjC81c!Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0Vmgg0xmj_C$>

Rgds
Shraddha

_______________________________________________
rtgwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtgwg<https://urldefense.com/v3/__https:/clicktime.symantec.com/35M9j5zHTaSYRwVh5RP6xcB6H2?u=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Frtgwg__;JSUlJSUl!8WoA6RjC81c!Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0VmgvV9Y4sM$>

___________________________________________________________________________

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.
___________________________________________________________________________

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 2 Dec 2019 06:54:13 +0000

Shraddha,
Lots of thanks for athe tesponse.

I probably did not express myself clearly enough. I will try to fix thst now, and I apologise in advance for a long email.

I have not been speaking about end-yo-end protecyion, only about local protection against failure of an intermediate (a.k.a. pinned) node of an SR path and, specifically, triggers for such protection. This context has been actually defined by Robert in his original comment.

To the best of my understanding, Robert's concern was that failure of the link beteeen the pinned node of a SR path and its adjacency (the penultimate node of the Segment represented by the Node SID of the pinned node) is not a good enough indication of the pinned node failure.

I agree with this statement even if my understanding of a good indication differs from Robert's:
- I think that it is not sufficiently specific and therefore could result in flapping (local node protection activated and then released)
-Robert's concern, to the best of my understanding, was that it could miss some failures (e.g. the Fabric failure).

Therefore I have suggested two possibilities for more specific and more rrliabke detection of failure of the pinned node by its adjacency:

1. Run a multi-hop IP BFD session between the peniltimate node ans the pinned ones using prefixes acting as Node SIDs of this pair.  This wiuld ignore link failures but locally detect such node failurs as power-down or crash.

2.  Run S-BFD sessions to all other adjacencies of the pinned node using in each case a list of two SIDs: the protected Adj-SID to the pinned node followed by tge Node SID of the other adjacency, ans declare pinned node failure when all these sessions fail. This would again ignore failure of the link between the penultimate node and the pinned node but detect various real failures of the pinned node, e.g. failure of its Fabric.

In any case I think that it woyld make sense to separate the protection scheme proposed in the draft from specific triggers for its activation similar to how this has been done in MPLS Egress Protection Framework draft.

My 2c.

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Shraddha Hegde <[email-masked]>
Sent: Monday, December 2, 2019, 06:10
To: Alexander Vainshtein; Robert Raszuk
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [spring] Draft for Node protection of intermediate nodes in SR Paths

Robert/Sasha,

Rgds
Shraddha

Robert,

What do you think?

Get Outlook for Android<https://clicktime.symantec.com/3MR8y7CviGLkS3kzg1UybRv6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Faka.ms%2Fghei36__%3B%218WoA6RjC81c%21Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0VmgnYBhAbc%24>

Robert,

My 2c.
Get Outlook for Android<https://clicktime.symantec.com/3MR8y7CviGLkS3kzg1UybRv6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Faka.ms%2Fghei36__%3B%218WoA6RjC81c%21Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0VmgnYBhAbc%24>

Hi Sasha,

Thx,
Robert.

My 2c,
Sasha

Such

Get Outlook for Android<https://clicktime.symantec.com/3NbK72q2ca668aVyMaT7Esn6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3CfVQPtBYBAPbHUSngEVNQD6H2%3Fu%3Dhttps%2A3A%2A2F%2A2Faka.ms%2A2Fghei36__%3BJSUlJQ%218WoA6RjC81c%21Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0Vmgujy50EN%24>

Hi Shraddha,

   has failed.

Many thx,
Robert.

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/3HvrzHXwAou2JruETj6jcyF6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F375SW6TBGPi2mN7V9YeVWGg6H2%3Fu%3Dhttps%2A3A%2A2F%2A2Ftools.ietf.org%2A2Fhtml%2A2Fdraft-hegde-spring-node-protection-for-sr-te-paths-05__%3BJSUlJSU%218WoA6RjC81c%21Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0Vmgg0xmj_C%24>

Rgds
Shraddha

_______________________________________________
rtgwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtgwg<https://clicktime.symantec.com/37ZvNSMSAddpxDGDQPm7oVA6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F35M9j5zHTaSYRwVh5RP6xcB6H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.org%2A2Fmailman%2A2Flistinfo%2A2Frtgwg__%3BJSUlJSUl%218WoA6RjC81c%21Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0VmgvV9Y4sM%24>

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 2 Dec 2019 07:24:01 +0000

Sasha,

We are in agreement on separating the trigger from the protection mechanism.

> In any case I think that it woyld make sense to separate the protection scheme proposed in the draft from specific triggers for its activation >similar to how this has been done in MPLS Egress Protection Framework draft.

I'll add text in the next revision for this.

Rgds
Shraddha

From: Alexander Vainshtein <[email-masked]>
Sent: Monday, December 2, 2019 12:24 PM
To: Shraddha Hegde <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Robert Raszuk <[email-masked]>
Subject: Re: [spring] Draft for Node protection of intermediate nodes in SR Paths

Shraddha,

My 2c.

Get Outlook for Android<https://urldefense.com/v3/__https:/aka.ms/ghei36__;!8WoA6RjC81c!QAhYaA0qhoUZ3yxQWl05Ap12CMR-J-RTL_O_d_wKElC5ktZrPekfTDhLH6GPZiIH$>

From: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>

Robert/Sasha,

Rgds
Shraddha

To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <[email-masked]<mailto:[email-masked]>>

Robert,

What do you think?

Get Outlook for Android<https://urldefense.com/v3/__https:/clicktime.symantec.com/3MR8y7CviGLkS3kzg1UybRv6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Faka.ms*2Fghei36__*3B*218WoA6RjC81c*21Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0VmgnYBhAbc*24__;JSUlJSUlJSUlJSUl!8WoA6RjC81c!QAhYaA0qhoUZ3yxQWl05Ap12CMR-J-RTL_O_d_wKElC5ktZrPekfTDhLH1YVygZC$>

Robert,

My 2c.
Get Outlook for Android<https://urldefense.com/v3/__https:/clicktime.symantec.com/3MR8y7CviGLkS3kzg1UybRv6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Faka.ms*2Fghei36__*3B*218WoA6RjC81c*21Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0VmgnYBhAbc*24__;JSUlJSUlJSUlJSUl!8WoA6RjC81c!QAhYaA0qhoUZ3yxQWl05Ap12CMR-J-RTL_O_d_wKElC5ktZrPekfTDhLH1YVygZC$>

Hi Sasha,

Thx,
Robert.

My 2c,
Sasha

Such

Get Outlook for Android<https://urldefense.com/v3/__https:/clicktime.symantec.com/3NbK72q2ca668aVyMaT7Esn6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F3CfVQPtBYBAPbHUSngEVNQD6H2*3Fu*3Dhttps*2A3A*2A2F*2A2Faka.ms*2A2Fghei36__*3BJSUlJQ*218WoA6RjC81c*21Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0Vmgujy50EN*24__;JSUlJSUlJSUlJSUlJSUlJSUl!8WoA6RjC81c!QAhYaA0qhoUZ3yxQWl05Ap12CMR-J-RTL_O_d_wKElC5ktZrPekfTDhLH7q73pAh$>

Hi Shraddha,

   has failed.

Many thx,
Robert.

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://urldefense.com/v3/__https:/clicktime.symantec.com/3HvrzHXwAou2JruETj6jcyF6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F375SW6TBGPi2mN7V9YeVWGg6H2*3Fu*3Dhttps*2A3A*2A2F*2A2Ftools.ietf.org*2A2Fhtml*2A2Fdraft-hegde-spring-node-protection-for-sr-te-paths-05__*3BJSUlJSU*218WoA6RjC81c*21Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0Vmgg0xmj_C*24__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!8WoA6RjC81c!QAhYaA0qhoUZ3yxQWl05Ap12CMR-J-RTL_O_d_wKElC5ktZrPekfTDhLH9RfbOqT$>

Rgds
Shraddha

_______________________________________________
rtgwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtgwg<https://urldefense.com/v3/__https:/clicktime.symantec.com/37ZvNSMSAddpxDGDQPm7oVA6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F35M9j5zHTaSYRwVh5RP6xcB6H2*3Fu*3Dhttps*2A3A*2A2F*2A2Fwww.ietf.org*2A2Fmailman*2A2Flistinfo*2A2Frtgwg__*3BJSUlJSUl*218WoA6RjC81c*21Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0VmgvV9Y4sM*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSU!8WoA6RjC81c!QAhYaA0qhoUZ3yxQWl05Ap12CMR-J-RTL_O_d_wKElC5ktZrPekfTDhLH_pG5Prx$>

---

From: Andrew Alston <[email-masked]>
Date: Mon, 2 Dec 2019 09:27:59 +0000

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
Node validation as defined in the SR-TE drafts is limited to presence in the IGP
Since SR-TE path injection may be done through reflectors - using target communities - the point of communication into the network is not necessarily the head end of the tunnel and the point of injection may be entirely unaware of the implications of the path that's being inserted.

By utilizing what is contained in this draft to build context tables at the head end of an inserted tunnel on an automated basis - this solves a problem that currently exists that S-BFD simply cannot solve without modification to the srte policy insertion drafts that would allow for automated building of S-BFD checks - which in and of itself could prove challenging considering the complexity of this.

That is not to say in any way that both s-bfd and potentially other mechanisms do not have use cases - but as an operator - this draft would certainly provide a better mechanism for constant path validation than anything we currently have (which is based on steered packets that leave the controller and return to the controller through the use of SR packets and binding sids).

Just my 2c

Thanks

Andrew

From: spring <[email-masked]> On Behalf Of Shraddha Hegde
Sent: Monday, 2 December 2019 10:24
To: Alexander Vainshtein <[email-masked]>
Cc: [email-masked]; [email-masked]; Robert Raszuk <[email-masked]>; [email-masked]
Subject: Re: [spring] Draft for Node protection of intermediate nodes in SR Paths

Sasha,

Rgds
Shraddha

From: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Sent: Monday, December 2, 2019 12:24 PM
To: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Draft for Node protection of intermediate nodes in SR Paths

Shraddha,

My 2c.

Robert/Sasha,

Rgds
Shraddha

Robert,

What do you think?

Robert,

My 2c.

Hi Sasha,

Thx,
Robert.

My 2c,
Sasha

Such

Hi Shraddha,

   has failed.

Many thx,
Robert.

Rgds
Shraddha

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 2 Dec 2019 10:49:31 +0100

On Mon, Dec 2, 2019 at 10:28 AM Andrew Alston <
[email-masked]> 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.

> Since SR-TE path injection may be done through reflectors – using target
> communities – the point of communication into the network is not
> necessarily the head end of the tunnel and the point of injection may be
> entirely unaware of the implications of the path that’s being inserted.
>
>
>
> By utilizing what is contained in this draft to build context tables at
> the head end of an inserted tunnel on an automated basis – this solves a
> problem that currently exists that S-BFD simply cannot solve without
> modification to the srte policy insertion drafts that would allow for
> automated building of S-BFD checks – which in and of itself could prove
> challenging considering the complexity of this.
>
>
>
> That is not to say in any way that both s-bfd and potentially other
> mechanisms do not have use cases – but as an operator – this draft would
> certainly provide a better mechanism for constant path validation than
> anything we currently have (which is based on steered packets that leave
> the controller and return to the controller through the use of SR packets
> and binding sids).
>
>
>
> Just my 2c
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
> *From:* spring <[email-masked]> *On Behalf Of *Shraddha Hegde
> *Sent:* Monday, 2 December 2019 10:24
> *To:* Alexander Vainshtein <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; Robert Raszuk <[email-masked]>;
> [email-masked]
> *Subject:* Re: [spring] Draft for Node protection of intermediate nodes
> in SR Paths
>
>
>
> Sasha,
>
>
>
> > In any case I think that it woyld make sense to separate the protection
> scheme proposed in the draft from specific triggers for its activation
> >similar to how this has been done in MPLS Egress Protection Framework
> draft.
>
>
>
> I’ll add text in the next revision for this.
>
>
>
> Rgds
>
> Shraddha
>
>
>
>
>
> *From:* Alexander Vainshtein <[email-masked]>
> *Sent:* Monday, December 2, 2019 12:24 PM
> *To:* Shraddha Hegde <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; [email-masked]; Robert Raszuk <
> [email-masked]>
> *Subject:* Re: [spring] Draft for Node protection of intermediate nodes
> in SR Paths
>
>
>
> Shraddha,
>
> I probably did not express myself clearly enough. I will try to fix thst
> now, and I apologise in advance for a long email.
>
>
>
> I have not been speaking about end-yo-end protecyion, only about local
> protection against failure of an intermediate (a.k.a. pinned) node of an SR
> path and, specifically, triggers for such protection. This context has been
> actually defined by Robert in his original comment.
>
>
>
> To the best of my understanding, Robert's concern was that failure of the
> link beteeen the pinned node of a SR path and its adjacency (the
> penultimate node of the Segment represented by the Node SID of the pinned
> node) is not a good enough indication of the pinned node failure.
>
>
>
> - I think that it is not sufficiently specific and therefore could result
> in flapping (local node protection activated and then released)
>
> Therefore I have suggested two possibilities for more specific and more
> rrliabke detection of failure of the pinned node by its adjacency:
>
>
>
> 1. Run a multi-hop IP BFD session between the peniltimate node ans the
> pinned ones using prefixes acting as Node SIDs of this pair.  This wiuld
> ignore link failures but locally detect such node failurs as power-down or
> crash.
>
>
>
> 2.  Run S-BFD sessions to all other adjacencies of the pinned node using
> in each case a list of two SIDs: the protected Adj-SID to the pinned node
> followed by tge Node SID of the other adjacency, ans declare pinned node
> failure when all these sessions fail. This would again ignore failure of
> the link between the penultimate node and the pinned node but detect
> various real failures of the pinned node, e.g. failure of its Fabric.
>
>
>
> In any case I think that it woyld make sense to separate the protection
> scheme proposed in the draft from specific triggers for its activation
> similar to how this has been done in MPLS Egress Protection Framework draft.
>
>
>
> My 2c.
>
>
>
>
>
>
>
>
>
>
>
>
>
> Get Outlook for Android
> <https://urldefense.com/v3/__https:/aka.ms/ghei36__;!8WoA6RjC81c!QAhYaA0qhoUZ3yxQWl05Ap12CMR-J-RTL_O_d_wKElC5ktZrPekfTDhLH6GPZiIH$>
>
>
> ------------------------------
>
> *From:* Shraddha Hegde <[email-masked]>
> *Sent:* Monday, December 2, 2019, 06:10
> *To:* Alexander Vainshtein; Robert Raszuk
> *Cc:* [email-masked]; [email-masked]; [email-masked]
> *Subject:* RE: [spring] Draft for Node protection of intermediate nodes
> in SR Paths
>
>
>
> Robert/Sasha,
>
>
>
>
>
> In many cases, node-protecting backup path will be different from
> link-protecting/SRLG protecting backup path.
>
> If you really want to use link-protecting backup path when link fails and
> node protecting backup path when node fails,
>
> *From:* Alexander Vainshtein <[email-masked]>
> *Sent:* Saturday, November 23, 2019 8:15 PM
> *To:* Robert Raszuk <[email-masked]>; Shraddha Hegde <
> [email-masked]>
> *Cc:* [email-masked]; [email-masked]; [email-masked]
> *Subject:* Re: [spring] Draft for Node protection of intermediate nodes
> in SR Paths
>
>
>
> Robert,
>
> On the second thought, for the purpose of this draft (i.e. in the scope of
> SR) it is possible to implement your suggestion by running S-BFD sessions
> between R7 (as the initiator) and each other adjacency of R8  (acting as
> Reflectors) of a SR policy with list of two SIDs:
>
> Get Outlook for Android
> <https://urldefense.com/v3/__https:/clicktime.symantec.com/3MR8y7CviGLkS3kzg1UybRv6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Faka.ms*2Fghei36__*3B*218WoA6RjC81c*21Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0VmgnYBhAbc*24__;JSUlJSUlJSUlJSUl!8WoA6RjC81c!QAhYaA0qhoUZ3yxQWl05Ap12CMR-J-RTL_O_d_wKElC5ktZrPekfTDhLH1YVygZC$>
>
>
> ------------------------------
>
> *From:* Alexander Vainshtein <[email-masked]>
> *Sent:* Saturday, November 23, 2019, 13:15
> *To:* Robert Raszuk; Shraddha Hegde
> *Cc:* [email-masked]; [email-masked]; [email-masked]
> *Subject:* Re: [spring] Draft for Node protection of intermediate nodes
> in SR Paths
>
>
>
> Robert,
>
> I respectfully disagree with your statement that BFD implementation  is
> usually offloaded to the HW of the ingress line card.  I do not think this
> can wor for MH BFD sessions because the ingress and egress line cards are
> not known in advance and change with the routing changes
>
> A good  multi-hop BFD implementation should be ready to overcome this..
> There are many ways to achieve that. A naive implementation that runs in SW
> of the control card is also possible of course. And they would sensd and
> receive packets
>
>
>
> My 2c.
>
> Get Outlook for Android
> <https://urldefense.com/v3/__https:/clicktime.symantec.com/3MR8y7CviGLkS3kzg1UybRv6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Faka.ms*2Fghei36__*3B*218WoA6RjC81c*21Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0VmgnYBhAbc*24__;JSUlJSUlJSUlJSUl!8WoA6RjC81c!QAhYaA0qhoUZ3yxQWl05Ap12CMR-J-RTL_O_d_wKElC5ktZrPekfTDhLH1YVygZC$>
>
>
> ------------------------------
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Saturday, November 23, 2019, 12:37
> *To:* Alexander Vainshtein; Shraddha Hegde
> *Cc:* [email-masked]; [email-masked]; [email-masked]
> *Subject:* Re: [spring] Draft for Node protection of intermediate nodes
> in SR Paths
>
>
>
> Hi Sasha,
>
>
>
> See - one of the biggest value of BFD is its offload to line card's
> hardware. And in most cases it is ingress line card to the box. So if you
> instruct such hardware to respond to SID address loopback you still did not
> gain much in terms of detection router's fabric failures, remote LC failure
> or control plane issues which could soon result in box failure. The
> catalogue of router failures is of course much more colorful.
>
>
>
> IMHO the best way to detect node failure is actually to send the probes
> *across* the node under test to its peers.
>
>
>
> The way I would think of establishing such m-hop sessions would be fully
> automated with one knob per IGP adj. ex: "bfd detect-node-failure [max N]"
> where local BFD subsystem would create N sessions to IGP peers of the node
> we are to protect. LSDB has those peers so no new protocol extension is
> needed, perhaps even no new IETF draft is required :). N would be the limit
> of such sessions in case the node under protection has say 10s of peers.
> Default could be perhaps even 1.
>
>
>
> Thx,
>
> Robert.
>
>
>
>
>
> On Sat, Nov 23, 2019 at 10:00 AM Alexander Vainshtein <
> [email-masked]> wrote:
>
> 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://urldefense.com/v3/__https:/clicktime.symantec.com/3NbK72q2ca668aVyMaT7Esn6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F3CfVQPtBYBAPbHUSngEVNQD6H2*3Fu*3Dhttps*2A3A*2A2F*2A2Faka.ms*2A2Fghei36__*3BJSUlJQ*218WoA6RjC81c*21Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0Vmgujy50EN*24__;JSUlJSUlJSUlJSUlJSUlJSUl!8WoA6RjC81c!QAhYaA0qhoUZ3yxQWl05Ap12CMR-J-RTL_O_d_wKElC5ktZrPekfTDhLH7q73pAh$>
>
>
> ------------------------------
>
> *From:* spring <[email-masked]> on behalf of Robert Raszuk <
> [email-masked]>
> *Sent:* Friday, November 22, 2019, 11:22
> *To:* Shraddha Hegde
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [spring] Draft for Node protection of intermediate nodes
> in SR Paths
>
>
>
> Hi Shraddha,
>
>
>
> 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:
>
>
>
> 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
> On Fri, Nov 22, 2019 at 4:38 AM Shraddha Hegde <shraddha=
> [email-masked]..org <[email-masked]>> wrote:
>
> WG,
>
>
>
> https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-05
> <https://urldefense.com/v3/__https:/clicktime.symantec.com/3HvrzHXwAou2JruETj6jcyF6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F375SW6TBGPi2mN7V9YeVWGg6H2*3Fu*3Dhttps*2A3A*2A2F*2A2Ftools.ietf.org*2A2Fhtml*2A2Fdraft-hegde-spring-node-protection-for-sr-te-paths-05__*3BJSUlJSU*218WoA6RjC81c*21Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0Vmgg0xmj_C*24__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!8WoA6RjC81c!QAhYaA0qhoUZ3yxQWl05Ap12CMR-J-RTL_O_d_wKElC5ktZrPekfTDhLH9RfbOqT$>
>
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg
> <https://urldefense.com/v3/__https:/clicktime.symantec.com/37ZvNSMSAddpxDGDQPm7oVA6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F35M9j5zHTaSYRwVh5RP6xcB6H2*3Fu*3Dhttps*2A3A*2A2F*2A2Fwww.ietf.org*2A2Fmailman*2A2Flistinfo*2A2Frtgwg__*3BJSUlJSUl*218WoA6RjC81c*21Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0VmgvV9Y4sM*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSU!8WoA6RjC81c!QAhYaA0qhoUZ3yxQWl05Ap12CMR-J-RTL_O_d_wKElC5ktZrPekfTDhLH_pG5Prx$>
>
>
>
>
>
>

---

From: Andrew Alston <[email-masked]>
Date: Mon, 2 Dec 2019 10:06:23 +0000

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 <[email-masked]>
Sent: Monday, 2 December 2019 12:50
To: Andrew Alston <[email-masked]>
Cc: Shraddha Hegde <shraddha=[email-masked]>; Alexander Vainshtein <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [spring] Draft for Node protection of intermediate nodes in SR Paths

On Mon, Dec 2, 2019 at 10:28 AM Andrew Alston <[email-masked]<mailto:[email-masked]>> 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.

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.

Node validation as defined in the SR-TE drafts is limited to presence in the IGP
Since SR-TE path injection may be done through reflectors – using target communities – the point of communication into the network is not necessarily the head end of the tunnel and the point of injection may be entirely unaware of the implications of the path that’s being inserted.

By utilizing what is contained in this draft to build context tables at the head end of an inserted tunnel on an automated basis – this solves a problem that currently exists that S-BFD simply cannot solve without modification to the srte policy insertion drafts that would allow for automated building of S-BFD checks – which in and of itself could prove challenging considering the complexity of this.

That is not to say in any way that both s-bfd and potentially other mechanisms do not have use cases – but as an operator – this draft would certainly provide a better mechanism for constant path validation than anything we currently have (which is based on steered packets that leave the controller and return to the controller through the use of SR packets and binding sids).

Just my 2c

Thanks

Andrew

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Shraddha Hegde
Sent: Monday, 2 December 2019 10:24
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Draft for Node protection of intermediate nodes in SR Paths

Sasha,

Rgds
Shraddha

Shraddha,

My 2c.

Robert/Sasha,

Rgds
Shraddha

Robert,

What do you think?

Robert,

My 2c.

Hi Sasha,

Thx,
Robert.

My 2c,
Sasha

Such

Hi Shraddha,

   has failed.

Many thx,
Robert.

Rgds
Shraddha

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 2 Dec 2019 11:14:15 +0100

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-ali-spring-bfd-sr-policy-02

Cheers,
R.

On Mon, Dec 2, 2019 at 11:06 AM Andrew Alston <
[email-masked]> wrote:

> 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 😊
>
>
>
> 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
>
> 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
>
>
>
>
>
> *Sent:* Monday, 2 December 2019 12:50
> *To:* Andrew Alston <[email-masked]>
> *Cc:* Shraddha Hegde <shraddha=[email-masked]>; Alexander
> Vainshtein <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]

---

From: Andrew Alston <[email-masked]>
Date: Mon, 2 Dec 2019 10:27:51 +0000

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

Sent: Monday, 2 December 2019 13:14

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 <[email-masked]<mailto:[email-masked]>> wrote:
Robert – actually I disagree.

It is empty
Its weight is 0

Thanks
Andrew

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Monday, 2 December 2019 12:50
To: Andrew Alston <[email-masked]<mailto:[email-masked]>>
Cc: Shraddha Hegde <shraddha=[email-masked]<mailto:[email-masked]>>; Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Draft for Node protection of intermediate nodes in SR Paths

Cheers,
r.

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 2 Dec 2019 09:44:34 -0500

Hi Sasha, et al.,
many thanks for the great discussion. Please correct me if my recollection
is not accurate, but at the time of RFC 4090 it was agreed, that a trigger
to local protection may be in fact a false negative and, as a result, the
protection switchover is suboptimal. I understand that as the realization
that there should be a practical and pragmatic balance between time to
detect a failure and the accuracy of characterizing it. I think, that the
draft Shraddha had mentioned, doesn't need to discuss any of these issues.
What I'm curious, as you've suggested to the possible use of S-BFD, what
then the detection time could be. Unlike with the asynchronous mode of BFD,
S-BFD, as I understand, doesn't have predictable detection time like
defined in Section 6.8.4 RFC 5880. The detection time by S-BFD, I believe,
characterizes RTT and RTT may vary from probe to probe significantly. True,
a system may gather S-BFD RTT statistics to set and periodically adjust the
detection time to achieve more accurate failure detection. But, in my view,
it seems like significant complexity comparing to RFC 5880.

Regards,
Greg

On Sat, Nov 23, 2019 at 9:45 AM Alexander Vainshtein <
[email-masked]> wrote:

> Get Outlook for Android <https://aka.ms/ghei36>
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
>> 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://clicktime.symantec.com/3CfVQPtBYBAPbHUSngEVNQD6H2?u=https%3A%2F%2Faka.ms%2Fghei36>
>>
>>> *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>
>>>
>>> <https://clicktime.symantec.com/35M9j5zHTaSYRwVh5RP6xcB6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frtgwg>
>>
>>
>
>