On Mon, Dec 2, 2019 at 10:28 AM Andrew Alston < 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. > 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 <spring-boun...@ietf.org> *On Behalf Of *Shraddha Hegde > *Sent:* Monday, 2 December 2019 10:24 > *To:* Alexander Vainshtein <alexander.vainsht...@ecitele.com> > *Cc:* spr...@ietf.org; rtg-bfd@ietf.org; Robert Raszuk <rob...@raszuk.net>; > rt...@ietf.org > *Subject:* Re: [spring] Draft for Node protection of intermediate nodes > in SR Paths > > > > 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 <alexander.vainsht...@ecitele.com> > *Sent:* Monday, December 2, 2019 12:24 PM > *To:* Shraddha Hegde <shrad...@juniper.net> > *Cc:* spr...@ietf.org; rt...@ietf.org; rtg-bfd@ietf.org; Robert Raszuk < > rob...@raszuk.net> > *Subject:* Re: [spring] Draft for Node protection of intermediate nodes > in SR Paths > > > > 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://urldefense.com/v3/__https:/aka.ms/ghei36__;!8WoA6RjC81c!QAhYaA0qhoUZ3yxQWl05Ap12CMR-J-RTL_O_d_wKElC5ktZrPekfTDhLH6GPZiIH$> > > > ------------------------------ > > *From:* Shraddha Hegde <shrad...@juniper.net> > *Sent:* Monday, December 2, 2019, 06:10 > *To:* Alexander Vainshtein; Robert Raszuk > *Cc:* spr...@ietf.org; rt...@ietf.org; rtg-bfd@ietf.org > *Subject:* RE: [spring] Draft for Node protection of intermediate nodes > in SR Paths > > > > 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 <alexander.vainsht...@ecitele.com> > *Sent:* Saturday, November 23, 2019 8:15 PM > *To:* Robert Raszuk <rob...@raszuk.net>; Shraddha Hegde < > shrad...@juniper.net> > *Cc:* spr...@ietf.org; rt...@ietf.org; rtg-bfd@ietf.org > *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:/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 <alexander.vainsht...@ecitele.com> > *Sent:* Saturday, November 23, 2019, 13:15 > *To:* Robert Raszuk; Shraddha Hegde > *Cc:* spr...@ietf.org; rt...@ietf.org; rtg-bfd@ietf.org > *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:/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 <rob...@raszuk.net> > *Sent:* Saturday, November 23, 2019, 12:37 > *To:* Alexander Vainshtein; Shraddha Hegde > *Cc:* spr...@ietf.org; rt...@ietf.org; rtg-bfd@ietf.org > *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 < > alexander.vainsht...@ecitele.com> 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/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 <spring-boun...@ietf.org> on behalf of Robert Raszuk < > rob...@raszuk.net> > *Sent:* Friday, November 22, 2019, 11:22 > *To:* Shraddha Hegde > *Cc:* spr...@ietf.org; rt...@ietf.org > *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 <shraddha= > 40juniper....@dmarc.ietf..org <40juniper....@dmarc.ietf.org>> 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:/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$> > > > > Review and comments solicited. > > > > Rgds > > Shraddha > > > > _______________________________________________ > rtgwg mailing list > rt...@ietf.org > 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$> > > > > > > > ___________________________________________________________________________ > > 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. > ___________________________________________________________________________ > > > > > ___________________________________________________________________________ > > 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. > ___________________________________________________________________________ >
