Re: [spring] Draft for Node protection of intermediate nodes in SR Paths
Robert Raszuk <robert@raszuk.net> Mon, 02 December 2019 09:49 UTC
Return-Path: <robert@raszuk.net>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43381200E7 for <rtgwg@ietfa.amsl.com>; Mon, 2 Dec 2019 01:49:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4X0r9Cj3Ss-g for <rtgwg@ietfa.amsl.com>; Mon, 2 Dec 2019 01:49:43 -0800 (PST)
Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA5FC1200A1 for <rtgwg@ietf.org>; Mon, 2 Dec 2019 01:49:42 -0800 (PST)
Received: by mail-qk1-x72b.google.com with SMTP id b8so16977244qkk.5 for <rtgwg@ietf.org>; Mon, 02 Dec 2019 01:49:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KxuiNkIBbzU+FuKfMCKC7PBN61R17o1iDCt6MpAlHqk=; b=TaYyzUxU9+Aa5Zm+ROijF2DokSSCjBZtB3vX0Hrv5hix3t51KHxDvfPIXUa9uWb6Wx d9pJKH/NnxLjBGlXobHEIkPP5pucxN7ds5sk3Jk4Rxudu5RXOb4oeevxcVI1vkfhKcV5 v5Trrl4brl4SBzdZAzhXKwEduJSaDLor+sfERx7qGAoASQPLFsm5bUJuWZCQB2GGQJKW NIP0MADuqd2/PBRcJBhvFG4VaPMUfsPYf7NoxpNcWExLbYlkzyoAru8nOfiY0CdSPH5a GjOwElS9LBIlWbu3O1rk37FF+4SiZnzAvrrupUUyZ/IOGcDPJNSbptfF7XKxDMWAzens Coqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KxuiNkIBbzU+FuKfMCKC7PBN61R17o1iDCt6MpAlHqk=; b=IpgnZfQbSJcsV7+FL5EuPAYe595zFCLd6GwdcbqsUiRmaQdtwxjspScqesD7lr+RlY Srz1GVBHrS84UtxJHRVfdfTmH7D01FkljImr4ehj08G392dGTqMeMu7JgD1mDPEV8gJG D5gVJynJiSOnagTf0Fvy91u7+/SrqdVPF5Vdu83uGP7UQ2H2bDNLH/aA478RrE+fJ9ua /lEPBwBN30tR2pQQm5praeiA9jeLLML5Elfxv9TuihFEAhlzYTUcop++rwgRf9xSv7FI YyT90Uk+LK1VGXL+EKU3owpwDV9ZO9UxJi3z/lDto/PvK9ZDywiBmbVm4XyhoP0Xaf3p xizA==
X-Gm-Message-State: APjAAAWumoGshyCFYQGE6mZ3hPcq1AlT37TseU2YmFldb/RkM0WaD8f/ /3/n+HqJU9tby1c1ehvQu1WawGbLNjtkgGUjjq4p2Q==
X-Google-Smtp-Source: APXvYqzzbfE5EXm8V2dsDLxcBmP37fLQeSe8ZNFe2AAA/RUuo9ZEuqSPwyAOAvd+NBS30K77xJ3H9dB3TLpGN+KZ3p0=
X-Received: by 2002:a37:62d2:: with SMTP id w201mr30470413qkb.445.1575280181381; Mon, 02 Dec 2019 01:49:41 -0800 (PST)
MIME-Version: 1.0
References: <BYAPR05MB394365C9E4719913BEC0809CD5490@BYAPR05MB3943.namprd05.prod.outlook.com> <CAOj+MMFOueodpR-06AN47aND6_9WJAwPaXMTaP-0nzd0HCVzKA@mail.gmail.com> <AM0PR03MB382893DAFDE830D24EE7FAD49D480@AM0PR03MB3828.eurprd03.prod.outlook.com> <CAOj+MMFzrMBTbQbRXrnN0HTNm=uH+HF_LGggVZ3WUtAzGQSNgQ@mail.gmail.com> <VI1PR03MB383986D0D2E66226BFDEDF839D480@VI1PR03MB3839.eurprd03.prod.outlook.com> <AM0PR03MB3828FD21B1D69E3CB74F3AE49D480@AM0PR03MB3828.eurprd03.prod.outlook.com> <BYAPR05MB3943CE8749F824CDDA88F3C8D5430@BYAPR05MB3943.namprd05.prod.outlook.com> <AM0PR03MB3828F1161645C155DA569F099D430@AM0PR03MB3828.eurprd03.prod.outlook.com> <BYAPR05MB394390FE9BEAC8D0CA71DECED5430@BYAPR05MB3943.namprd05.prod.outlook.com> <DBBPR03MB5415486F24D2C9B6338611BEEE430@DBBPR03MB5415.eurprd03.prod.outlook.com>
In-Reply-To: <DBBPR03MB5415486F24D2C9B6338611BEEE430@DBBPR03MB5415.eurprd03.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 02 Dec 2019 10:49:31 +0100
Message-ID: <CAOj+MME2EM52zF8j0N6+8kYpkPz2AN2JP0uMP4JYZcxOgXqGcw@mail.gmail.com>
Subject: Re: [spring] Draft for Node protection of intermediate nodes in SR Paths
To: Andrew Alston <Andrew.Alston@liquidtelecom.com>
Cc: Shraddha Hegde <shraddha=40juniper.net@dmarc.ietf.org>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, "spring@ietf.org" <spring@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a223b50598b57f1c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/s6-UjRDlwUbNMA7n9ewbYm-ULuI>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Dec 2019 09:49:46 -0000
On Mon, Dec 2, 2019 at 10:28 AM Andrew Alston < Andrew.Alston@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-bounces@ietf.org> *On Behalf Of *Shraddha Hegde > *Sent:* Monday, 2 December 2019 10:24 > *To:* Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> > *Cc:* spring@ietf.org; rtg-bfd@ietf.org; Robert Raszuk <robert@raszuk.net>; > rtgwg@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.Vainshtein@ecitele.com> > *Sent:* Monday, December 2, 2019 12:24 PM > *To:* Shraddha Hegde <shraddha@juniper.net> > *Cc:* spring@ietf.org; rtgwg@ietf.org; rtg-bfd@ietf.org; Robert Raszuk < > robert@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 <shraddha@juniper.net> > *Sent:* Monday, December 2, 2019, 06:10 > *To:* Alexander Vainshtein; Robert Raszuk > *Cc:* spring@ietf.org; rtgwg@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.Vainshtein@ecitele.com> > *Sent:* Saturday, November 23, 2019 8:15 PM > *To:* Robert Raszuk <robert@raszuk.net>; Shraddha Hegde < > shraddha@juniper.net> > *Cc:* spring@ietf.org; rtgwg@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.Vainshtein@ecitele.com> > *Sent:* Saturday, November 23, 2019, 13:15 > *To:* Robert Raszuk; Shraddha Hegde > *Cc:* spring@ietf.org; rtgwg@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 <robert@raszuk.net> > *Sent:* Saturday, November 23, 2019, 12:37 > *To:* Alexander Vainshtein; Shraddha Hegde > *Cc:* spring@ietf.org; rtgwg@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.Vainshtein@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-bounces@ietf.org> on behalf of Robert Raszuk < > robert@raszuk.net> > *Sent:* Friday, November 22, 2019, 11:22 > *To:* Shraddha Hegde > *Cc:* spring@ietf.org; rtgwg@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.net@dmarc.ietf..org <40juniper.net@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 > rtgwg@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. > ___________________________________________________________________________ >
- Draft for Node protection of intermediate nodes i… Shraddha Hegde
- Re: Draft for Node protection of intermediate nod… Robert Raszuk
- Re: [spring] Draft for Node protection of interme… Alexander Vainshtein
- Re: [spring] Draft for Node protection of interme… Robert Raszuk
- Re: [spring] Draft for Node protection of interme… Alexander Vainshtein
- Re: [spring] Draft for Node protection of interme… Alexander Vainshtein
- Re: [spring] Draft for Node protection of interme… Alexander Vainshtein
- RE: Draft for Node protection of intermediate nod… Shraddha Hegde
- RE: [spring] Draft for Node protection of interme… Shraddha Hegde
- Re: [spring] Draft for Node protection of interme… Alexander Vainshtein
- RE: [spring] Draft for Node protection of interme… Shraddha Hegde
- RE: [spring] Draft for Node protection of interme… Andrew Alston
- Re: [spring] Draft for Node protection of interme… Robert Raszuk
- RE: [spring] Draft for Node protection of interme… Andrew Alston
- Re: [spring] Draft for Node protection of interme… Robert Raszuk
- RE: [spring] Draft for Node protection of interme… Andrew Alston
- Node failure detection (was Re: [spring] Draft fo… Greg Mirsky