Re: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

[Alia Atlas <[e-mail]>]

On Wed, Jun 14, 2017 at 9:02 AM, Hannes Gredler <[e-mail]> wrote:

> hi alia,
>
> the issue at hand IMO does not warrant an errata.
>
> this is more related to how ARP & nexthop handling
> is performed internally in a routing-stack which is IMO a bit outside
> of what isis-wg should work on.
>

I agree that it is a bit outside the scope - but the issue comes up
from interactions.   I am happy to reject the errata, if that is the
consensus, but I could use a clearly written note explaining why.
I'm also fine with having it become an advisory note; I think it is
useful to provide non-normative guidance.

Regards,
Alia



>
> /hannes
>
> On 6/13/17 23:18, Alia Atlas wrote:
> > Chris, Hannes, Les, Sasha,
> >
> > Is there a conclusion about this Errata report?
> >
> > From the discussion, it sounds like there is a problem and the argument
> > is about
> > what layer it should be handled by.  Perhaps, instead of normative text,
> > it could be
> > a note?
> >
> > Regards,
> > Alia
> >
> > On Sun, May 7, 2017 at 1:35 AM, Alexander Vainshtein
> > <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     Naiming,____
> >
> >     Lots of thanks for a very detailed response.____
> >
> >     __ __
> >
> >     I fully agree with you that reasonable ARP implementations
> >     (including Linux) provide for enabling or disabling the check of the
> >     source IP address. ____
> >
> >     I also agree that disabling this check on unnumbered P2P-over-LAN
> >     interfaces is the most useful use case when this check must be
> >     disabled.____
> >
> >     __ __
> >
> >     I also agree that the if a pair of connected interfaces are
> >     configured with IP addresses from mismatched subnets, traffic would
> >     not pass unless ARP check is relaxed for both LAN and P2P
> >     interfaces. My point is that, in the case of OSPF, if the interfaces
> >     were not configured as P2P, */an OSPF adjacency would not be
> >     formed/*. Therefore the link would not be part of the network graph
> >     and not taken into account in the OSPF routes computation. ____
> >
> >     __ __
> >
> >     But if these interfaces are configured as P2P for OSPF, an adjacency
> >     is formed and it reaches its FULL state. The result is blackholing,
> >     and RFC 5309 neither instructs the operators to avoid such
> >     configuration nor requires from the implementations to relax the ARP
> >     check.____
> >
> >     __ __
> >
> >     Regards,____
> >
> >     Sasha____
> >
> >     __ __
> >
> >     Office: [phone] <tel:+972%203-926-6302>____
> >
> >     Cell:      [phone] <tel:+972%2054-926-6302>____
> >
> >     Email:   [e-mail]
> >     <mailto:[e-mail]>____
> >
> >     __ __
> >
> >     *From:*Naiming Shen (naiming) [mailto:[e-mail]
> >     <mailto:[e-mail]>]
> >     *Sent:* Friday, May 05, 2017 8:44 AM
> >
> >
> >     *To:* Alexander Vainshtein <[e-mail]
> >     <mailto:[e-mail]>>
> >     *Cc:* Les Ginsberg (ginsberg) <[e-mail]
> >     <mailto:[e-mail]>>; [e-mail]
> >     <mailto:[e-mail]>; RFC Errata System
> >     <[e-mail] <mailto:[e-mail]>>;
> >     [e-mail]
> >     <mailto:[e-mail]>; [e-mail]
> >     <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>;
> >     Alvaro Retana (aretana) <[e-mail]
> >     <mailto:[e-mail]>>; [e-mail]
> >     <mailto:[e-mail]>; [e-mail] <mailto:
> [e-mail]>
> >     *Subject:* Re: [Isis-wg] [Technical Errata Reported] RFC5309
> (5007)____
> >
> >     __ __
> >
> >     __ __
> >
> >     Sasha,____
> >
> >     __ __
> >
> >     Thanks for the comments.____
> >
> >     __ __
> >
> >     In OS implementations, in particular linux, there are various
> >     releases and____
> >
> >     configure options, so it varies quite a bit for ARP. This pointer
> >     shows how to change____
> >
> >     the ARP behavior on linux:____
> >
> >     __ __
> >
> >     http://kb.linuxvirtualserver.org/wiki/Using_arp_announce/
> arp_ignore_to_disable_ARP
> >     <http://kb.linuxvirtualserver.org/wiki/Using_arp_announce/
> arp_ignore_to_disable_ARP>____
> >
> >     __ __
> >
> >     For example, the variable ‘arp_ignore’, has the code sample in
> >     ‘arp.c’:____
> >
> >     http://elixir.free-electrons.com/linux/latest/source/net/ipv4/arp.c
> >     <http://elixir.free-electrons.com/linux/latest/source/net/ipv4/arp.c
> >____
> >
> >     __ __
> >
> >     static int arp_ignore
> >     <http://elixir.free-electrons.com/linux/latest/ident/arp_ignore
> >(struct
> >     in_device
> >     <http://elixir.free-electrons.com/linux/latest/ident/in_device>
> >     *in_dev, __be32
> >     <http://elixir.free-electrons.com/linux/latest/ident/__be32> sip
> >     <http://elixir.free-electrons.com/linux/latest/ident/sip>, __be32
> >     <http://elixir.free-electrons.com/linux/latest/ident/__be32>
> tip)____
> >
> >     {____
> >
> >                         struct net *net = dev_net
> >     <http://elixir.free-electrons.com/linux/latest/ident/dev_net
> >(in_dev->dev);____
> >
> >                         int scope
> >     <http://elixir.free-electrons.com/linux/latest/ident/scope>;____
> >
> >     __ __
> >
> >                         switch (IN_DEV_ARP_IGNORE
> >     <http://elixir.free-electrons.com/linux/latest/ident/IN_DEV_
> ARP_IGNORE>(in_dev))
> >     {____
> >
> >                         case 0:          /* Reply, the tip is already
> >     validated */____
> >
> >                                              return 0;____
> >
> >                         case 1:          /* Reply only if tip is
> >     configured on the incoming interface */____
> >
> >                                              sip
> >     <http://elixir.free-electrons.com/linux/latest/ident/sip> = 0;____
> >
> >                                              scope
> >     <http://elixir.free-electrons.com/linux/latest/ident/scope> =
> >     RT_SCOPE_HOST
> >     <http://elixir.free-electrons.com/linux/latest/ident/RT_SCOPE_HOST
> >;____
> >
> >                                              break;____
> >
> >                         case 2:          /*____
> >
> >                                              * Reply only if tip is
> >     configured on the incoming interface____
> >
> >                                              * and is in same subnet as
> >     sip____
> >
> >                                              */____
> >
> >                                              scope
> >     <http://elixir.free-electrons.com/linux/latest/ident/scope> =
> >     RT_SCOPE_HOST
> >     <http://elixir.free-electrons.com/linux/latest/ident/RT_SCOPE_HOST
> >;____
> >
> >                                              break;____
> >
> >     I have two linux boxes with ubuntu 16.04 connected on an ethernet
> ____
> >
> >     and with two different subnet:____
> >
> >     lenovo (enp3s0 with IP 192.168.1.35/24 <http://192.168.1.35/24>) <—>
> >     vaio (enp2s8 with IP 192.168.2.100/24 <http://192.168.2.100/24>)____
> >
> >     __ __
> >
> >     on vaio: I run an arping to request ARP resolution of 192.168.1.35
> >     <http://192.168.1.35>:____
> >
> >     vaio:~$ sudo arping 192.168.1.35 -i enp2s8____
> >
> >     60 bytes from ec:a8:6b:c0:82:23 (192.168.1.35): index=0 time=6.538
> >     msec____
> >
> >     60 bytes from ec:a8:6b:c0:82:23 (192.168.1.35): index=1 time=1.464
> >     msec____
> >
> >     60 bytes from ec:a8:6b:c0:82:23 (192.168.1.35): index=2 time=8.418
> >     msec____
> >
> >     __ __
> >
> >     I made sure on lenovo as described arp_announce is ‘2’, and
> >     arp_ignore is ‘0’:____
> >
> >     root@lenovo:/proc/sys/net/ipv4/conf/enp3s0# echo 2 > arp_announce
> ____
> >
> >     root@lenovo:/proc/sys/net/ipv4/conf/enp3s0# cat arp_ignore ____
> >
> >     __ __
> >
> >     Run tcpdump on lenovo interface enp3s0 to get ARP packets:____
> >
> >     root@lenovo:/proc/sys/net/ipv4/conf/enp3s0# tcpdump -i enp3s0 arp
> >     -vv____
> >
> >     __ __
> >
> >     22:14:01.774491 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
> >     192.168.1.35 tell 192.168.2.100, length 46____
> >
> >     22:14:01.774511 ARP, Ethernet (len 6), IPv4 (len 4), Reply
> >     192.168.1.35 is-at ec:a8:6b:c0:82:23 (oui Unknown), length 28____
> >
> >     22:14:02.775522 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
> >     192.168.1.35 tell 192.168.2.100, length 46____
> >
> >     22:14:02.775541 ARP, Ethernet (len 6), IPv4 (len 4), Reply
> >     192.168.1.35 is-at ec:a8:6b:c0:82:23 (oui Unknown), length 28____
> >
> >     __ __
> >
> >     __ __
> >
> >     Ok, so what I’m getting at is that, if you know the system needs to
> >     run____
> >
> >     numbered and mismatched IP addresses over the same cable, then____
> >
> >     regardless of p2p-over-lan or other applications, you probably need
> >     to____
> >
> >     adjust the local ARP behavior to match what is expected on the
> OS.____
> >
> >     __ __
> >
> >     I agree that RFC 5309 does mention the matching IP subnet, and
> >     probably____
> >
> >     should refer to unnumbered is the most useful use case.____
> >
> >     __ __
> >
> >     Best Regards,____
> >
> >     - Naiming____
> >
> >     __ __
> >
> >         On May 1, 2017, at 12:40 AM, Alexander Vainshtein
> >         <[e-mail]
> >         <mailto:[e-mail]>> wrote:____
> >
> >         __ __
> >
> >         Naiming,____
> >
> >         Lots of thanks for a prompt response.____
> >
> >          ____
> >
> >         Unfortunately, I do not think that your response addresses your
> >         concern.____
> >
> >          ____
> >
> >         RFC 5309 explicitly mentions “ARP implementation (which /checks
> >         that the subnet of the source address of the ARP request matches
> >         the local interface address/)”. Actually, ARP implementations
> >         frequently check that /the source IP address in an ARP request
> >         is in the subnet of the local interface address/. E.g., AFAIK,
> >         this is the standard behavior of the Linux ARP implementation.
> >         To the best of my understanding this was the check that RFC 5309
> >         implied, /because there is no way the subnet of the source
> >         address of the ARP request could be known/.____
> >
> >          ____
> >
> >         If such check is applied, then the scenario I’ve described
> >         becomes valid. I can add that I have observed several
> >         implementations that experience the described behavior (i.e.,
> >         blackholing of unicast IP traffic that OSPF tries to route via
> >         such a link). Some other implementations seem to behave
> better.____
> >
> >          ____
> >
> >         Regards,____
> >
> >         Sasha____
> >
> >          ____
> >
> >          ____
> >
> >          ____
> >
> >          ____
> >
> >          ____
> >
> >         Regards,____
> >
> >         Sasha____
> >
> >          ____
> >
> >         Office: [phone] <tel:+972%203-926-6302>____
> >
> >         Cell:      [phone] <tel:+972%2054-926-6302>____
> >
> >         Email:   [e-mail]
> >         <mailto:[e-mail]>____
> >
> >          ____
> >
> >         *From:* Naiming Shen (naiming) [mailto:[e-mail]]
> >         *Sent:* Monday, May 01, 2017 5:34 AM
> >         *To:* Alexander Vainshtein <[e-mail]
> >         <mailto:[e-mail]>>
> >         *Cc:* Les Ginsberg (ginsberg) <[e-mail]
> >         <mailto:[e-mail]>>; [e-mail]
> >         <mailto:[e-mail]>; RFC Errata System
> >         <[e-mail] <mailto:[e-mail]>>;
> >         [e-mail]
> >         <mailto:[e-mail]>; [e-mail]
> >         <mailto:[e-mail]>; [e-mail]
> >         <mailto:[e-mail]>; Alvaro Retana (aretana)
> >         <[e-mail] <mailto:[e-mail]>>;
> >         [e-mail] <mailto:[e-mail]>; [e-mail]
> >         <mailto:[e-mail]>
> >         *Subject:* Re: [Isis-wg] [Technical Errata Reported] RFC5309
> >         (5007)____
> >
> >          ____
> >
> >          ____
> >
> >         Alexander, ____
> >
> >          ____
> >
> >         If you are saying the local LAN interface is explicitly
> >         configured with____
> >
> >         a different subnet IP address then the peer, I don’t think there
> >         is any____
> >
> >         problem with the ARP, and also with this RFC. Since ARP will
> >         always____
> >
> >         reply to answer its own IP addresses on the interface upon
> >         request.____
> >
> >          ____
> >
> >         This RFC is only saying, if it’s p2p-over-lan over an unnumbered
> >         IP address,____
> >
> >         and this LAN interface needs to proxy-ARP the IP address it
> >         binds to.____
> >
> >         If the ARP already replies since you have an IP address, and
> our____
> >
> >         p2p-over-LAN intf also uses this IP address, nothing is
> broken.____
> >
> >          ____
> >
> >         thanks.____
> >
> >         - Naiming____
> >
> >          ____
> >
> >             On Apr 30, 2017, at 8:50 AM, Alexander Vainshtein
> >             <[e-mail]
> >             <mailto:[e-mail]>> wrote:____
> >
> >              ____
> >
> >             Les,____
> >
> >             Lots of thanks for a prompt response.____
> >
> >              ____
> >
> >             As I see it, the difference between the P2P and LAN modes is
> >             essential for OSPF:____
> >
> >             - If an OSPF interface is a LAN (broadcast) interface, there
> >             is a check of the same subnet for received Hello packets. If
> >             the received Hello packets do not pass this check, they are
> >             discarded and an error is reported via SNMP.____
> >
> >             - However, if an OSPF interface is a P2P interface, then the
> >             subnet check on the Hello packets is bypassed  by design as
> >             defined in Section 10.5 of RFC 2328:____
> >
> >                    ____
> >
> >                                  The generic input processing of OSPF
> >             packets will____
> >
> >                     have checked the validity of the IP header and the
> >             OSPF packet____
> >
> >                     header.  Next, the values of the Network Mask,
> >             HelloInterval,____
> >
> >                     and RouterDeadInterval fields in the received Hello
> >             packet must____
> >
> >                     be checked against the values configured for the
> >             receiving____
> >
> >                     interface.  Any mismatch causes processing to stop
> >             and the____
> >
> >                     packet to be dropped.  In other words, the above
> >             fields are____
> >
> >                     really describing the attached network's
> >             configuration. However,____
> >
> >                     there is one exception to the above rule: on
> >             point-to-point____
> >
> >                     networks and on virtual links, the Network Mask in
> >             the received____
> >
> >                     Hello Packet should be ignored.____
> >
> >              ____
> >
> >             I.e., having different subnets on two ends of a PPP link
> >             would not cause any problems for OSPF - the adjacency would
> >             be successfully recognized, it would progress to its FULL
> >             state, and unicast traffic would cross such a link without
> >             any problem.____
> >
> >              ____
> >
> >             But if we have a P2P-over-LAN link (which is the case for
> >             RFC 5309), the result would be quite different - unless the
> >             ARP implementations go beyond what 5309 says and relax the
> >             check for all such links, be they numbered or unnumbered.____
> >
> >              ____
> >
> >             Do I miss something substantial here?____
> >
> >              ____
> >
> >              ____
> >
> >              ____
> >
> >             Regards,____
> >
> >             Sasha____
> >
> >              ____
> >
> >             Office: [phone] <tel:+972%203-926-6302>____
> >
> >             Cell:      [phone] <tel:+972%2054-926-6302>____
> >
> >             Email:   [e-mail]
> >             <mailto:[e-mail]>____
> >
> >              ____
> >
> >              ____
> >
> >             -----Original Message-----
> >             From: Les Ginsberg (ginsberg) [mailto:[e-mail]]
> >             Sent: Sunday, April 30, 2017 5:19 PM
> >             To: RFC Errata System <[e-mail]
> >             <mailto:[e-mail]>>; Naiming Shen (naiming)
> >             <[e-mail]
> >             <mailto:[e-mail]>>;[e-mail]
> >             <mailto:[e-mail]>; [e-mail]
> >             <mailto:[e-mail]>; [e-mail]
> >             <mailto:[e-mail]>; Alvaro Retana (aretana)
> >             <[e-mail]
> >             <mailto:[e-mail]>>; [e-mail]
> >             <mailto:[e-mail]>; [e-mail]
> >             <mailto:[e-mail]>
> >             Cc: Alexander Vainshtein <[e-mail]
> >             <mailto:[e-mail]>>; [e-mail]
> >             <mailto:[e-mail]>
> >             Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309
> >             (5007)____
> >
> >              ____
> >
> >             Alexander -____
> >
> >              ____
> >
> >             I am not speaking for the RFC authors, but regarding your
> >             point:____
> >
> >              ____
> >
> >             > o          Are assigned with IP addresses and subnet masks
> yielding different____
> >
> >             > subnets____
> >
> >              ____
> >
> >             I fail to see why this issue is unique to (or associated
> >             with) running in P2P mode.____
> >
> >              ____
> >
> >             The unnumbered case is specifically mentioned because in
> >             such a case it can be expected that the next hop address
> >             will be a loopback address and therefore there will be no
> >             common subnet.____
> >
> >             But in the numbered case whether you have one neighbor in
> >             P2P mode or many neighbors in multi-access mode the
> >             msimatched subnet issue is the same. Therefore I see no
> >             reason why these RFCs should discuss it.____
> >
> >              ____
> >
> >             ???____
> >
> >              ____
> >
> >                Les____
> >
> >              ____
> >
> >              ____
> >
> >             > -----Original Message-----____
> >
> >             > From: Isis-wg [mailto:[e-mail]
> >             <mailto:[e-mail]>] On Behalf Of RFC____
> >
> >             > Errata System____
> >
> >             > Sent: Sunday, April 30, 2017 1:16 AM____
> >
> >             > To: Naiming Shen (naiming); [e-mail]
> >             <mailto:[e-mail]>;____
> >
> >             > [e-mail]
> >             <mailto:[e-mail]>; [e-mail]
> >             <mailto:[e-mail]>; Alvaro Retana (aretana);____
> >
> >             > [e-mail]
> >             <mailto:[e-mail]>; [e-mail]
> >             <mailto:[e-mail]>____
> >
> >             > Cc: [e-mail]
> >             <mailto:[e-mail]>; [e-mail]
> >             <mailto:[e-mail]>;____
> >
> >             > rfc-editor@rfc- editor.org
> >             <http://webdefence.global.blackspider.com/urlwrap/?q=
> AXicE3RmiL7GwDDlCANDUU6lgUmSXnFRmV5uYmZOcn5eSVF-
> jl5yfi5DmYmhUUREcLmBkaGRuQmDY05qRWJeSmqRXlhiZl5xRklqZp5DanJm
> SWpOKlh9RklJgZW-fmpKZkl-kV5-UToDA0PFQQYGAOFQJGs&Z>____
> >
> >             > Subject: [Isis-wg] [Technical Errata Reported] RFC5309
> (5007)____
> >
> >             > ____
> >
> >             > The following errata report has been submitted for
> RFC5309,____
> >
> >             > "Point-to-Point Operation over LAN in Link State Routing
> Protocols".____
> >
> >             > ____
> >
> >             > --------------------------------------____
> >
> >             > You may review the report below and at:____
> >
> >             > http://www.rfc-editor.org/errata_search.php?rfc=5309&
> eid=5007
> >             <http://www.rfc-editor.org/errata_search.php?rfc=5309&
> eid=5007>____
> >
> >             > ____
> >
> >             > --------------------------------------____
> >
> >             > Type: Technical____
> >
> >             > Reported by: Alexander Vainshtein <
> [e-mail]
> >             <mailto:[e-mail]>>____
> >
> >             > ____
> >
> >             > Section: 4.3____
> >
> >             > ____
> >
> >             > Original Text____
> >
> >             > -------------____
> >
> >             > For the ARP implementation (which checks that the subnet
> of the source____
> >
> >             > address of the ARP request matches the local interface
> address), this____
> >
> >             > check needs to be relaxed for the unnumbered p2p-over-lan
> circuits.____
> >
> >             > ____
> >
> >             > Corrected Text____
> >
> >             > --------------____
> >
> >             > For the ARP implementation (which checks that the subnet
> of the source____
> >
> >             > address of the ARP request matches the local interface
> address), this____
> >
> >             > check needs to be relaxed for the p2p-over-lan circuits
> (both numbered____
> >
> >             > and unnumbered).____
> >
> >             > ____
> >
> >             > Notes____
> >
> >             > -----____
> >
> >             > Consider the following situation:____
> >
> >             > 1.         Two routers, R1 and R2, are connected by a
> physical P2P  Ethernet____
> >
> >             > link____
> >
> >             > 2.         OSPFv2 is enabled on the interfaces
> representing the endpoints of____
> >
> >             > this link.____
> >
> >             > 3.      From the OSPF POV these interfaces:____
> >
> >             > o          Are configured as P2P____
> >
> >             > o          Belong to the same area____
> >
> >             > o          Are assigned with IP addresses and subnet masks
> yielding different____
> >
> >             > subnets____
> >
> >             > 4.    ARP check mentioned in the problematic text is not
> relaxed.____
> >
> >             > ____
> >
> >             > Under this conditions:____
> >
> >             > -Both R1 and R2 will accept Hello messages sent by the
> other router____
> >
> >             > (becase it ignores subnet in Hello messages received via
> P2P____
> >
> >             > interfaces)____
> >
> >             > - Adjacency between R1 and R2 will progress to FULL state
> (because all____
> >
> >             > OSPFv2 messages will be sent with AllSPFRouters multicast
> IPv4____
> >
> >             > address)____
> >
> >             > - Unicast traffic sent by R1 to R2 (and vice versa) will
> be blackholed____
> >
> >             > because ARP will not resolve addresses assigned to the
> corresponding interfaces.____
> >
> >             > ____
> >
> >             > Instructions:____
> >
> >             > -------------____
> >
> >             > This erratum is currently posted as "Reported". If
> necessary, please____
> >
> >             > use "Reply All" to discuss whether it should be verified
> or rejected.____
> >
> >             > When a decision is reached, the verifying party can log in
> to change____
> >
> >             > the status and edit the report, if necessary.____
> >
> >             > ____
> >
> >             > --------------------------------------____
> >
> >             > RFC5309 (draft-ietf-isis-igp-p2p-over-lan-06)____
> >
> >             > --------------------------------------____
> >
> >             > Title               : Point-to-Point Operation over LAN in
> Link State Routing____
> >
> >             > Protocols____
> >
> >             > Publication Date    : October 2008____
> >
> >             > Author(s)           : N. Shen, Ed., A. Zinin, Ed.____
> >
> >             > Category            : INFORMATIONAL____
> >
> >             > Source              : IS-IS for IP Internets____
> >
> >             > Area                : Routing____
> >
> >             > Stream              : IETF____
> >
> >             > Verifying Party     : IESG____
> >
> >             > ____
> >
> >             > ___________________________________________________
> >
> >             > Isis-wg mailing list____
> >
> >             > [e-mail] <mailto:[e-mail]>____
> >
> >             > https://www.ietf.org/mailman/listinfo/isis-wg
> >             <https://www.ietf.org/mailman/listinfo/isis-wg>____
> >
> >
> >             ____________________________________________________________
> _______________
> >
> >             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.
> >         ____________________________________________________________
> ___________________
> >
> >     __ __
> >
> >
> >     ____________________________________________________________
> _______________
> >
> >     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.
> >     ____________________________________________________________
> _______________
> >
> >
>