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

Shraddha Hegde <shraddha@juniper.net> Mon, 02 December 2019 05:09 UTC

Return-Path: <shraddha@juniper.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 E995812012C; Sun, 1 Dec 2019 21:09:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level:
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, 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_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=m4JiQuc/; dkim=pass (1024-bit key) header.d=juniper.net header.b=EwQABzkB
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 ABnxoAsOZiBP; Sun, 1 Dec 2019 21:09:56 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 126BC120041; Sun, 1 Dec 2019 21:09:56 -0800 (PST)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xB2575eW016401; Sun, 1 Dec 2019 21:09:52 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=dFaUB8u/T4GgqS7ea878Mup/pfu2d85EgKGRoVI55Es=; b=m4JiQuc/JCHNbGgYu2utf4tZ/NpMeFw68237IWg/8612vNjyWYohYPJP52Vf9MoVQIdI 5ppZL8MTYrnKvre/HPDM+T+Xkk9Dp8/Pw6Zn4GGZcvOdMrjKLxp5wOy/2CCPkdCyqiaa xlpICCq16bRwiWXx9FCtdT0Bb9t1N9Y/kmQxC/2ee0QKUCKdY1ed5L0KhoSZ5itdxMGd T9B+DcPL/G8Oq01ZD0RlD8kDfxAjWhyzkpqWZG0WNJDaIndrZE9Ffy+q7NHWRzaUEfcR uRVg1EkTBnUc9B6T3/Pm7xf6eiOXV9A420R5SpiET2JjY1LoeL+HswVHANYPpX24d6CD sw==
Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp2051.outbound.protection.outlook.com [104.47.40.51]) by mx0a-00273201.pphosted.com with ESMTP id 2wkraqhy89-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 01 Dec 2019 21:09:52 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QaD5otUcyjCDDyK3OC7OreRYe+BHW8BypcnE+/Ty20V36SO48LR925gW/nfdz0KVMMtKsFRSxy7BY5wNdXDU7kp/uFwDUFPDtvaRZCq9NIZwPufvyuYXjqnwmgMkWtaT8t1ntyM1dnkeBZFVfjBLpPD0Iy1TPGTbv3Bq4vOKQOlmg4fK4KbacrXswpmXL5LcXsdSevvftILJVPC7wq607YGacRymULB3LeSzvEfZuFzKs5BAmltON2TGqqSDKbgVEILimMdvjJOx4SSRFfjnOqQS8glFoVh9UH8FiYdKaG4jiLJ0S2u1HmMaJSO2LAqE7EgRCmEsEt1bh3A9WU2nHw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dFaUB8u/T4GgqS7ea878Mup/pfu2d85EgKGRoVI55Es=; b=Van8oyY4M1q/M9gkmvSOkGIx7m4l9g8MVA63gYltYgCEagw/jqH3vN+o6ml4g4A256MIbdcEWBR/eILIKl291e3lWNI8Dyk39M0nlgZv23DT4xP1sC+l4szBbyqIQoGgpO++ckYayhExn9fSZk9gtDWShuXU0OFKoBz2gknDbQ9I0qAIwMnuPi0cNy+UfT01oI7RU0tkFtcicEqjHC7vCSoY1Fo+rsarZPoPdqkcoh5KeLAzMwPGOEAmMzgZuswpNiC5q8RdNh60HPMUeJj6gRAdpLiCpz8PKNINSHwYpfr/J+C13yUgfleQCFssqj05llozLhIudK9FMILGWVCkjw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dFaUB8u/T4GgqS7ea878Mup/pfu2d85EgKGRoVI55Es=; b=EwQABzkBK0TrFEv8cRWFVAMh/fC9jKgHbiDgWEM1VCNadhflycYBZ9U2b1nDNDPXO5zlxbhBcuGbqnt/Y4bToUy8FjOmqvegtoSDlVOOM/AA46jgc3R8AMOs3q+xOm2V2vMRU3dqBW1OpLegikYZ71Ks1OmUSHc3pztWwZTHyno=
Received: from BYAPR05MB3943.namprd05.prod.outlook.com (52.135.197.146) by BYAPR05MB5559.namprd05.prod.outlook.com (20.177.127.93) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.9; Mon, 2 Dec 2019 05:09:49 +0000
Received: from BYAPR05MB3943.namprd05.prod.outlook.com ([fe80::d6c:bedb:6c67:8a26]) by BYAPR05MB3943.namprd05.prod.outlook.com ([fe80::d6c:bedb:6c67:8a26%6]) with mapi id 15.20.2495.014; Mon, 2 Dec 2019 05:09:49 +0000
From: Shraddha Hegde <shraddha@juniper.net>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, Robert Raszuk <robert@raszuk.net>
CC: "spring@ietf.org" <spring@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: RE: [spring] Draft for Node protection of intermediate nodes in SR Paths
Thread-Topic: [spring] Draft for Node protection of intermediate nodes in SR Paths
Thread-Index: AQHVoRZpcWzNT/yCAUirnVoRkUsBfqeYdqqAgAAbMICAAAqSgIAAOoiAgA2Aw7A=
Date: Mon, 02 Dec 2019 05:09:49 +0000
Message-ID: <BYAPR05MB3943CE8749F824CDDA88F3C8D5430@BYAPR05MB3943.namprd05.prod.outlook.com>
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>
In-Reply-To: <AM0PR03MB3828FD21B1D69E3CB74F3AE49D480@AM0PR03MB3828.eurprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_ActionId=5ef8f343-e749-40b6-9ef2-0000a81ae678; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_ContentBits=0; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_Enabled=true; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_Method=Standard; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_Name=Juniper Business Use Only; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_SetDate=2019-12-02T04:57:07Z; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4;
dlp-product: dlpe-windows
dlp-version: 11.2.0.14
dlp-reaction: no-action
x-originating-ip: [116.197.184.15]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 69314c75-76ff-4dab-9a82-08d776e5db36
x-ms-traffictypediagnostic: BYAPR05MB5559:
x-microsoft-antispam-prvs: <BYAPR05MB5559C1D3D49A41BD169B8069D5430@BYAPR05MB5559.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:4714;
x-forefront-prvs: 0239D46DB6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(396003)(39860400002)(136003)(346002)(54094003)(199004)(189003)(186003)(7696005)(5070765005)(76116006)(74316002)(110136005)(66476007)(76176011)(99286004)(26005)(316002)(45080400002)(66946007)(81166006)(6436002)(66066001)(86362001)(14444005)(478600001)(256004)(966005)(52536014)(54896002)(790700001)(6116002)(6306002)(236005)(66446008)(64756008)(66556008)(9686003)(55016002)(7736002)(3846002)(54906003)(14454004)(5660300002)(25786009)(102836004)(446003)(33656002)(229853002)(6506007)(4326008)(81156014)(71200400001)(71190400001)(53546011)(8676002)(8936002)(66574012)(606006)(440504004)(517774005)(11346002)(2906002)(561944003)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB5559; H:BYAPR05MB3943.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: mE48PEVIOFu/kUPk0SjM0JJDa56IspID6pgsCOt0gL0//EsND0BciTF1rTi8T0UrVv3irktd1mW6NoJSPHdniEUUUIn6mr71P8hf6mckxqEJLfPmbx/Ac5kjgdy94/p+zBt4LJ6yzA5Zt7NuzXG5bq3ccLb6EtYwtTdkiX9vBke5ivWFCVWd2lh85SLhVOT7xpdy1DUKpQUOhBJkBaxdlFrHziUz2hvzHqK1wBTQjh7Zd0IoRDj2ivlBPvX6Rf75m+ikY+xG5JYO7X1D8IJOCzds/KmxqLRPsSeiLSgZOaW5ohFtCAd7QJ++38rAKgBdbQialfzqtUe/KqVMgvneWnsjn17w/prjezRw03E6y39Izs00svJjMxSmyPwr9QJFQZFQ0DtGZhSvuXt6UOdXlA/S1Vm2FKkYelg8Sh/G/j3HRUzMFq+cFM0Im3rtNrlZT4xZvbUSZOCH6z3hVc2FTyZaHpEVwh8NHK53qR8XKgk=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BYAPR05MB3943CE8749F824CDDA88F3C8D5430BYAPR05MB3943namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 69314c75-76ff-4dab-9a82-08d776e5db36
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2019 05:09:49.1712 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: pyM12+qmKqLSPSAX+lIzUpYeKGf6CQVE8Ptzdgf+rhJ4ilL9sYurI/7XkyiTGBOAzTfr+9hi8EKZE5Z/RVOvkw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5559
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-01_04:2019-11-29,2019-12-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 lowpriorityscore=0 malwarescore=0 priorityscore=1501 suspectscore=0 impostorscore=0 bulkscore=0 mlxscore=0 mlxlogscore=999 phishscore=0 clxscore=1011 spamscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912020044
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/pteTFJaRGPRtv5m-sqg4pTyZ0bg>
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 05:09:58 -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 <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:/aka.ms/ghei36__;!8WoA6RjC81c!Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0VmgnYBhAbc$>

________________________________
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>>
Sent: Saturday, November 23, 2019, 13:15
To: Robert Raszuk; Shraddha Hegde
Cc: spring@ietf.org<mailto:spring@ietf.org>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>; rtg-bfd@ietf.org<mailto: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:/aka.ms/ghei36__;!8WoA6RjC81c!Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0VmgnYBhAbc$>

________________________________
From: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Sent: Saturday, November 23, 2019, 12:37
To: Alexander Vainshtein; Shraddha Hegde
Cc: spring@ietf.org<mailto:spring@ietf.org>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>; rtg-bfd@ietf.org<mailto: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<mailto: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/3CfVQPtBYBAPbHUSngEVNQD6H2?u=https*3A*2F*2Faka.ms*2Fghei36__;JSUlJQ!8WoA6RjC81c!Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0Vmgujy50EN$>

________________________________
From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> on behalf of Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Sent: Friday, November 22, 2019, 11:22
To: Shraddha Hegde
Cc: spring@ietf.org<mailto:spring@ietf.org>; rtgwg@ietf.org<mailto: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<mailto: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/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$>

Review and comments solicited.

Rgds
Shraddha

_______________________________________________
rtgwg mailing list
rtgwg@ietf.org<mailto:rtgwg@ietf.org>
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.
___________________________________________________________________________