IPv6 Address Planning
Currently we are in the process of planning our IPv6 addressing schema for our network. We are a service provider with around 20 core routers, and several hundred enterprise customers. These customers currently connect back to our core via a separate VLANs or channelized DS1/DS3/OC-X type interfaces. Thus currently lots of /30 IPv4 blocks. Our address allocation is 2001:1940::/32 Here is our current plan, but we are looking for suggestions from people who have been down this road before. The plan is to break out a /48 for our organization. Then break out the first /64 for loopbacks, and the next /64 for point-to-point connections. The PTP /64 then breaks out further into 1 /80 for core links, and 1 /80 for each of our distribution sites. Within these /80's are individual /112's for PTP links. What this will allow us to do is aggregate each sites PTP connections into /80's within our IGP. Looks something like this. 2001:1940::/48 - TransAria 2001:1940::/64 - Loopbacks/NMS/ETC 2001:1940::1/128 - Router 1 2001:1940::2/128 - Router 2 2001:1940:0:1::/64 - PTP Links 2001:1940:1::/80 - Core Links (non-aggergratable) 2001:1940:0:1::/112 - Core Link 1 2001:1940:0:1::1 - Router A 2001:1940:0:1::2 - Router B 2001:1940:0:1::1:1/112 - Core Link 2 2001:1940:0:1::1:1 - Router A 2001:1940:0:1::1:2 - Router B 2001:1940:0:1:1::/80 - Distribution Site 1 2001:1940:0:1:1::/112 - Customer Link 1 2001:1940:0:1:1::1 - Dist Router 2001:1940:0:1:1::2 - Customer Equipment 2001:1940:0:1:1:0:1:0/112 - Customer Link 2 2001:1940:0:1:1:0:1:1 - Dist Router 2001:1940:0:1:1:0:1:2 - Customer Equipment 2001:1940:0:1:2::/80 - Distribution Site 2 2001:1940:0:1:2:::/112 - Customer Link 1 2001:1940:0:1:2::1 - Dist Router 2001:1940:0:1:2::2 - Customer Equipment 2001:1940:0:1:2:0:1:0/112 2001:1940:0:1:2:0:1:1 - Dist Router 2001:1940:0:1:2:0:1:1 - Customer Equipment 2001:1940:1::/48 - Customer 1 Assignment 2001:1940:2::/48 - Customer 2 Assignment 2001:1940:3::/48 - Customer 3 Assignment Thoughts? Thanks! Cody
RE: IPv6 Address Planning
Makes sense. However the PTP addresses need to be internally visible from an NMS perspective in our network. -C -Original Message- From: James [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 09, 2005 12:13 PM To: Cody Lerum Cc: nanog@merit.edu Subject: Re: IPv6 Address Planning On Tue, Aug 09, 2005 at 11:24:22AM -0600, Cody Lerum wrote: Currently we are in the process of planning our IPv6 addressing schema for our network. We are a service provider with around 20 core routers, and several hundred enterprise customers. These customers currently connect back to our core via a separate VLANs or channelized DS1/DS3/OC-X type interfaces. Thus currently lots of /30 IPv4 blocks. Our address allocation is 2001:1940::/32 Here is our current plan, but we are looking for suggestions from people who have been down this road before. The plan is to break out a /48 for our organization. Then break out the first /64 for loopbacks, and the next /64 for point-to-point connections. The PTP /64 then breaks out further into 1 /80 for core links, and 1 /80 for each of our distribution sites. Within these /80's are individual /112's for PTP links. What this will allow us to do is aggregate each sites PTP connections into /80's within our IGP. The way we do it currently are as follows: Reserve a /48 for backbone pointopoints (eg. 2001:4830:ff::/48) in US, fe::/48 in EU. Reserve a /48 for loopbacks, and use /128s for each loopback out of that. As for point to point links, we currently use simple /64 subnets for each point to point (i.e. 2001:4830:ff:1500::/64, etc where ::1 and ::2 are routers on either side of the circuit). From there, we also have a /48 allocated per each POP for transfer networks at that location for peering via pni and customer hand-offs. Each xfer net is broken off as /64 out of that /48. We currently do not perform any PTP link aggregation in our IGP, we simply ensure only passive-interfaces are announced to IGP, thus PTP links are not even present in the IGP table (only loopbacks and xfer nets/bgp next-hops are). It is not perfect but works well currently and scales just fine for us. shameless plug You may also find the ipv6-ops list helpful for v6 rollout discussions: http://lists.cluenet.de/mailman/listinfo/ipv6-ops /shameless plug James -- James Jun Infrastructure and Technology Services TowardEX Technologies Office +1-617-459-4051 x179 | Mobile +1-978-394-2867 [EMAIL PROTECTED] | www.towardex.com
RE: Multi-link Frame Relay OR Load Balancing
If your using Cisco hardware make sure that the IOS versions used on both sides support 8 next-hops for load balancing. 12.3(9) on a 7206 only supported 6 in one situation, and thus the Juniper on one end forwarded over all 8 T1's where the 7206 only forwarded over 6. From my research at the time it appears that the number off next-hops supported varied by IOS ver. -C -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher L. Morrow Sent: Thursday, September 16, 2004 3:53 PM To: Bryce Enevoldson Cc: [EMAIL PROTECTED] Subject: Re: Multi-link Frame Relay OR Load Balancing On Thu, 16 Sep 2004, Bryce Enevoldson wrote: We are in the process of updating our internet connection to 8 t1's bound together. Due to price, our options have been narrowed to ATT and MCI. I have two questions: 1. Which technology is better for binding t1's: multi link frame relay (mci's) or load balancing (att's) of course, as always... not mci's view on the world ;) depends on what you want... do you want more than a 1.5mbps flow to pass? or do you just want to get 9mb of bandwidth and you don't care about max flow size? The MFR stuff will allow your link to look like a 9mb path, not 6 1.5mb paths. The load balancing makes it look like 6 l.5mb paths. 2. Which company has a better pop in Atlanta: mci or att? i'll avoid this question since I'm not equiped to answer as anything but a marketting answer :) We are in the Chattanooga TN area and our current connection is 6 t1's through att but they will only bond 4 so they are split 4 and 2. Some folks have said in the last that over 6mb of bandwidth it might be better/cheaper/easier to just get a fractional/burstable DS3 to meet your needs. -Chris
RE: Peering point speed publicly available?
DNS can sometimes give you a hint [my nets snipped] 4 t3-1-2-0.ar2.SEA1.gblx.net (64.211.206.113) 20.436 ms 18.309 ms 17.605 ms DS3 5 so1-0-0-2488M.ar4.SEA1.gblx.net (67.17.71.210) 17.607 ms 16.982 ms 16.971 ms -OC-486 p3-3.IR1.Seattle-WA.us.xo.net (206.111.7.5) 17.864 ms 19.491 ms 17.181 ms7 p5-1-0-3.RAR1.Seattle-WA.us.xo.net (65.106.0.197) 17.723 ms 17.632 ms 19.045 ms8 65.106.0.50 (65.106.0.50) 38.133 ms 39.197 ms 49.961 ms MPLS Label=101549 CoS=0 TTL=1 S=19 p0-0-0d0.RAR1.SanJose-CA.us.xo.net (65.106.1.61) 37.669 ms 38.572 ms 36.517 ms10 p7-0.DCR1.DC-SanJose-CA.us.xo.net (65.106.2.146) 37.830 ms 36.524 ms 37.743 ms11 ge1-1.CDR2.DC-SanJose-CA.us.xo.net (209.220.168.10) 38.428 ms 38.050 ms 37.179 ms -Gig Ethernet12 205.158.6.100.ptr.us.xo.net (205.158.6.100) 40.179 ms 39.784 ms 39.444 ms13 x218.cd9e6c.sj.concentric.net (205.158.108.218) 39.188 ms 39.723 ms 39.895 ms However MPLS hidden hops may hide internal paths, and any connection may be limited to slower than its line rate, and dns entries may be old It's not publicly available at one source that I'm aware of, and if there is they don't have my info. -C From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Erik AmundsonSent: Thursday, July 01, 2004 6:10 PMTo: [EMAIL PROTECTED]Cc: [EMAIL PROTECTED]Subject: Peering point speed publicly available? NANOG, I have a question regarding information on my ISPs peering relationships. Are the speeds of some or all peering relationships public knowledge, and if so, where can I find this? By speed, I mean bandwidth (DS3, OC3, 100Mbps, 1Gbps, etc.). I am trying to transfer large stuff from my AS, through my ISP, through another ISP, to another AS, and Im wondering how fast the peering point is between the ISPs. Im working with my provider to get this information as we speak, but Im wondering if its available publicly anywhere. If it were, this could be one way to evaluate providers in the future, I guess Erik AmundsonA+, N+, CCNA, CCNPIT and NetworkManagerOpen Access Technology Int'l, Inc.Phone (763) 201-2005Fax (763) 553-2813 mailto:[EMAIL PROTECTED]
RE: Peering point speed publicly available?
Very true.. Work with the network operators on each side of the link to determine the speed/load. For the most part if they really want your business, they will be able to provide something. The main reason link speed maybe important to me would serialization delay on the circuit. OC-768 should be much lower latency than a T1...unless your are at the end of the queue :-) Latency is probably be your primary concern for large TCP transfers anyway. -C -Original Message- From: Tony Li [mailto:[EMAIL PROTECTED] Sent: Thursday, July 01, 2004 7:02 PM To: Cody Lerum Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Peering point speed publicly available? Is it really important to know the link speeds? What good does it do without knowing about the loading on those links? I would MUCH rather have an empty T1 than have to contend with a very oversubscribed OC-768. Tony On Jul 1, 2004, at 5:25 PM, Cody Lerum wrote: DNS can sometimes give you a hint [my nets snipped] 4 t3-1-2-0.ar2.SEA1.gblx.net (64.211.206.113) 20.436 ms 18.309 ms 17.605 ms DS3 5 so1-0-0-2488M.ar4.SEA1.gblx.net (67.17.71.210) 17.607 ms 16.982 ms 16.971 ms -OC-48 6 p3-3.IR1.Seattle-WA.us.xo.net (206.111.7.5) 17.864 ms 19.491 ms 17.181 ms 7 p5-1-0-3.RAR1.Seattle-WA.us.xo.net (65.106.0.197) 17.723 ms 17.632 ms 19.045 ms 8 65.106.0.50 (65.106.0.50) 38.133 ms 39.197 ms 49.961 ms MPLS Label=101549 CoS=0 TTL=1 S=1 9 p0-0-0d0.RAR1.SanJose-CA.us.xo.net (65.106.1.61) 37.669 ms 38.572 ms 36.517 ms 10 p7-0.DCR1.DC-SanJose-CA.us.xo.net (65.106.2.146) 37.830 ms 36.524 ms 37.743 ms 11 ge1-1.CDR2.DC-SanJose-CA.us.xo.net (209.220.168.10) 38.428 ms 38.050 ms 37.179 ms -Gig Ethernet 12 205.158.6.100.ptr.us.xo.net (205.158.6.100) 40.179 ms 39.784 ms 39.444 ms 13 x218.cd9e6c.sj.concentric.net (205.158.108.218) 39.188 ms 39.723 ms 39.895 ms However MPLS hidden hops may hide internal paths, and any connection may be limited to slower than its line rate, and dns entries may be old It's not publicly available at one source that I'm aware of, and if there is they don't have my info. -C From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Erik Amundson Sent: Thursday, July 01, 2004 6:10 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Peering point speed publicly available? NANOG, I have a question regarding information on my ISP's peering relationships. Are the speeds of some or all peering relationships public knowledge, and if so, where can I find this? By speed, I mean bandwidth (DS3, OC3, 100Mbps, 1Gbps, etc.). I am trying to transfer large stuff from my AS, through my ISP, through another ISP, to another AS, and I'm wondering how fast the peering point is between the ISPs. I'm working with my provider to get this information as we speak, but I'm wondering if it's available publicly anywhere. If it were, this could be one way to evaluate providers in the future, I guess... Erik Amundson A+, N+, CCNA, CCNP IT and Network Manager Open Access Technology Int'l, Inc. Phone (763) 201-2005 Fax (763) 553-2813 mailto:[EMAIL PROTECTED]
RE: ultradns reachability
Well http://www.dnsstuff.com is showing it also (http://www.dnsstuff.com/tools/lookup.ch?name=mariners.orgtype=A) How I am searching: Searching for A record for mariners.org at j.root-servers.net: Got referral to TLD2.ULTRADNS.NET. [took 93 ms] Searching for A record for mariners.org at TLD2.ULTRADNS.NET.: Timed out. Trying again. Searching for A record for mariners.org at TLD2.ULTRADNS.NET.: Timed out. Trying again. Searching for A record for mariners.org at TLD2.ULTRADNS.NET.: Timed out. Trying again. Searching for A record for mariners.org at TLD1.ULTRADNS.NET.: Timed out. Trying again. Searching for A record for mariners.org at TLD2.ULTRADNS.NET.: Got referral to NS2.DIGISLE.NET. [took 473 ms] Searching for A record for mariners.org at NS2.DIGISLE.NET.: Reports mariners.org. [took 49 ms] Answer: Domain Type Class TTL Answer mariners.org. A IN 3600 216.74.142.14 mariners.org. NS IN 3600 ns1.digisle.net. mariners.org. NS IN 3600 ns2.digisle.net. ns1.digisle.net. A IN 172800 167.216.250.42 ns2.digisle.net. A IN 172800 167.216.193.233 -C -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Ghali Sent: Thursday, July 01, 2004 7:01 PM To: [EMAIL PROTECTED] Subject: ultradns reachability is anyone else seeing timeouts reaching ultradns' .org nameservers? I'm seeing seemingly random timeout failures from both sbci and uc berkeley.
RE: Peering point speed publicly available?
Latency does have a impact on TCP transfers, now granted the difference between a oc-3 and oc-192 is negligible, but if you stack a lot of T1 connections back to back its going to be a factor in your max throughput across the path. (Stats below might not exactly be accurate...snipped from another site) DS3: (1500 bytes * 8 bits/byte) / 44040192 bits/sec = .27 ms (approx) DS1: (1500 bytes * 8 bits/byte) / 1572864 bits/sec = 8 ms (approx) DS0: (1500 bytes * 8 bits/byte) / 65536 bits/sec = 183 ms (approx) If you don't think it does then run some ftp transfers end to end with 1ms of delay, and with 100ms, 200ms, 500ms, 1000 ms I never said that .002 microseconds is going to have a noticeable difference, but those 10ms - 20ms hops starts to add up. As well as propagation delay as you stated. -C -Original Message- From: Richard A Steenbergen [mailto:[EMAIL PROTECTED] Sent: Thursday, July 01, 2004 7:30 PM To: Cody Lerum Cc: Tony Li; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Peering point speed publicly available? On Thu, Jul 01, 2004 at 07:05:51PM -0600, Cody Lerum wrote: Work with the network operators on each side of the link to determine the speed/load. For the most part if they really want your business, they will be able to provide something. Actually, many larger peering relationships come with contracts which explicitly forbid them from telling you any details about link capacity or utilization, or in some cases even acknowledging that peering exists. They might tell you anyways though. :) For the most part, it is hope for descriptive DNS or bust. For the most part, DNS is not descriptive (especially on peering links). :) The main reason link speed maybe important to me would serialization delay on the circuit. OC-768 should be much lower latency than a T1...unless your are at the end of the queue :-) Once you get past 10Mbps, serialization delay is measured in fractions of a millisecond. This has absolutely no impact on TCP performance, compared to speed of light delays (like from oh say a 50ft patch cable). Latency is probably be your primary concern for large TCP transfers anyway. I think that you are very confused about how TCP works. 4 t3-1-2-0.ar2.SEA1.gblx.net (64.211.206.113) 20.436 ms 18.309 ms 17.605 ms DS3 5 so1-0-0-2488M.ar4.SEA1.gblx.net (67.17.71.210) 17.607 ms 16.982 ms 16.971 ms -OC-48 6 p3-3.IR1.Seattle-WA.us.xo.net (206.111.7.5) 17.864 ms 19.491 ms 17.181 ms Name:p3-3.IR1.Seattle-WA.us.xo.net Address: 206.111.7.5 Name:206.111.7.6.ptr.us.xo.net Address: 206.111.7.6 Sometimes you can find descriptive DNS on the other side of the PTR, and sometimes you find missing data. In this case, there is no speed description at all. The p3-3 interface indicates that this is a PoS interface, probably Cisco, and the IR designation on XO indicates a peering router. Educated hunch based on what the traffic levels between 3549 and 2828 in Seattle probably are... OC3? -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
RE: Peering point speed publicly available?
Not to mention I have run across a few providers who skew their dns records to make their network look bigger/faster. Like I said it might get you a vague idea, but I wouldnt place money on it. Just like GE might really be 10GE and FE might only be limited to 10Mbps. How often do you think IP's get moved around, and the DNS doesn't? -C -Original Message- From: Daniel Golding [mailto:[EMAIL PROTECTED] Sent: Thursday, July 01, 2004 8:02 PM To: Cody Lerum; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Peering point speed publicly available? Sometimes it can give a hint. However, if the ISPs are following the interface name convention, youll get something like P3-1-2, which just tells you its Packet Over SONET. That can mean anything from OC-3 to OC-192. ge could mean 10 gige :) The 2488M from glbx is nice, but not too common. It would be so nice if this were standardized between all providers. But naming conventions are really political - they sometimes provoke huge fights even within providers. -- Daniel Golding Network and Telecommunications Strategies Burton Group On 7/1/04 8:25 PM, Cody Lerum [EMAIL PROTECTED] wrote: DNS can sometimes give you a hint [my nets snipped] 4 t3-1-2-0.ar2.SEA1.gblx.net (64.211.206.113) 20.436 ms 18.309 ms 17.605 ms DS3 5 so1-0-0-2488M.ar4.SEA1.gblx.net (67.17.71.210) 17.607 ms 16.982 ms 16.971 ms -OC-48 6 p3-3.IR1.Seattle-WA.us.xo.net (206.111.7.5) 17.864 ms 19.491 ms 17.181 ms 7 p5-1-0-3.RAR1.Seattle-WA.us.xo.net (65.106.0.197) 17.723 ms 17.632 ms 19.045 ms 8 65.106.0.50 (65.106.0.50) 38.133 ms 39.197 ms 49.961 ms MPLS Label=101549 CoS=0 TTL=1 S=1 9 p0-0-0d0.RAR1.SanJose-CA.us.xo.net (65.106.1.61) 37.669 ms 38.572 ms 36.517 ms 10 p7-0.DCR1.DC-SanJose-CA.us.xo.net (65.106.2.146) 37.830 ms 36.524 ms 37.743 ms 11 ge1-1.CDR2.DC-SanJose-CA.us.xo.net (209.220.168.10) 38.428 ms 38.050 ms 37.179 ms -Gig Ethernet 12 205.158.6.100.ptr.us.xo.net (205.158.6.100) 40.179 ms 39.784 ms 39.444 ms 13 x218.cd9e6c.sj.concentric.net (205.158.108.218) 39.188 ms 39.723 ms 39.895 ms However MPLS hidden hops may hide internal paths, and any connection may be limited to slower than its line rate, and dns entries may be old It's not publicly available at one source that I'm aware of, and if there is they don't have my info. -C From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Erik Amundson Sent: Thursday, July 01, 2004 6:10 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Peering point speed publicly available? NANOG, I have a question regarding information on my ISPs peering relationships. Are the speeds of some or all peering relationships public knowledge, and if so, where can I find this? By speed, I mean bandwidth (DS3, OC3, 100Mbps, 1Gbps, etc.). I am trying to transfer large stuff from my AS, through my ISP, through another ISP, to another AS, and Im wondering how fast the peering point is between the ISPs. Im working with my provider to get this information as we speak, but Im wondering if its available publicly anywhere. If it were, this could be one way to evaluate providers in the future, I guess Erik Amundson A+, N+, CCNA, CCNP IT and Network Manager Open Access Technology Int'l, Inc. Phone (763) 201-2005 Fax (763) 553-2813 mailto:[EMAIL PROTECTED]
Level 3 Issues?
Depending on the Yahoo you get...66.218.71.198 traceroute to 66.218.71.198 (66.218.71.198), 30 hops max, 38 byte packets 1 ge-0-3-0-7-1q-4crn-bzn.mt.core.cutthroatcom.net (209.137.232.209) 0.398 ms 0.297 ms 0.315 ms 2 fe-0-0-0-rf-45m-silo-bzn.mt.core.cutthroatcom.net (209.137.235.194) 0.812 ms 0.750 ms 0.642 ms 3 fe-0-0-0-rf-45m-bxt-bzn.mt.core.cutthroatcom.net (209.137.235.202) 1.811 ms 1.593 ms 1.082 ms 4 t3-0-0-3-ta-hln.mt.core.cutthroatcom.net (209.137.235.218) 7.689 ms 6.538 ms 7.005 ms 5 t3-1-2-0.ar2.SEA1.gblx.net (64.211.206.113) 20.444 ms 20.485 ms 18.041 ms 6 so1-1-0-2488M.ar1.SJC2.gblx.net (67.17.64.65) 44.443 ms 41.470 ms 37.794 ms 7 so-4-0-0.edge1.SanJose1.Level3.net (4.68.127.53) 41.383 ms 40.958 ms 41.587 ms 8 so-1-2-0.bbr1.SanJose1.Level3.net (209.244.3.137) 48.844 ms 46.521 ms 41.600 ms 9 ge-9-1.ipcolo3.SanJose1.Level3.net (64.159.2.73) 43.877 ms ge-10-1.ipcolo3.SanJose1.Level3.net (64.159.2.105) 43.767 ms 46.232 ms 10 unknown.Level3.net (64.152.69.30) 476.219 ms 476.244 ms 480.827 ms 11 * UNKNOWN-66-218-82-230.yahoo.com (66.218.82.230) 495.937 ms 12 * alteon4.68.scd.yahoo.com (66.218.68.13) 486.236 ms 495.863 ms Anyone else seeing this? From www.dnsstuff.com as well Pinging 66.218.71.198 [66.218.71.198]: Ping #1: Got reply from 66.218.71.198 in 551ms [TTL=234] Ping #2: Got reply from 66.218.71.198 in 590ms [TTL=234] Ping #3: Got reply from 66.218.71.198 in 552ms [TTL=234] Ping #4: Got reply from 66.218.71.198 in 550ms [TTL=234] Done pinging 66.218.71.198! -C
RE: Yahoo mail public notice of problems ?
Ditto- Frequent delays in sending to yahoo.com -C -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Loftis Sent: Thursday, June 17, 2004 1:53 PM To: [EMAIL PROTECTED] Subject: Re: Yahoo mail public notice of problems ? --On Thursday, June 17, 2004 15:00 -0400 Mike Tancsa [EMAIL PROTECTED] wrote: Is there a notice I can point non Yahoo Mail customers to explaining why there are delivery delays? We are seeing a lot of stalled deliveries again, and it would be nice to point to an explanation by yahoo as to whats up Stalls are both at the banner not coming up Seeing the same thing as well... apparently not isolated. As far as a notice or anything I'm not aware of any. Email Confidentiality Notice: The information contained in this transmission is confidential, proprietary or privileged and may be subject to protection under the law, including the Health Insurance Portability and Accountability Act (HIPAA). The message is intended for the sole use of the individual or entity to whom it is addressed. If you are not the intended recipient, you are notified that any use, distribution or copying of the message is strictly prohibited and may subject you to criminal or civil penalties. If you received this transmission in error, please contact the sender immediately by replying to this email and delete the material from any computer.
