April 2005 - Test - lists.nanog.org

FW: [ipv6-wg@ripe.net] [afnog] New IPv6 Address Block Allocated to RIPE NCC
by Leslie Nobile 20 Apr '05

20 Apr '05

-----Original Message----- From: ipv6-wg-admin(a)ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of leo vegoda Sent: Thursday, December 16, 2004 8:57 AM To: address-policy-wg(a)ripe.net; routing-wg(a)ripe.net; ipv6-wg(a)ripe.net Cc: afnog(a)afnog.org Subject: [ipv6-wg(a)ripe.net] [afnog] New IPv6 Address Block Allocated to RIPE NCC Dear Colleagues, The RIPE NCC received the IPv6 address range 2001:4C00::/23 from the IANA in December 2004. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: <https://www.ripe.net/ripe/docs/smallest-alloc-sizes.html> Regards, -- leo vegoda Registration Services Manager RIPE NCC _______________________________________________ afnog mailing list afnog(a)afnog.org http://listserv2.cfi.co.ug/mailman/listinfo/afnog

1 0

Verizon's DSL Still Partially Clothed
by Fergie (Paul Ferguson) 19 Apr '05

19 Apr '05

Apparently, Verizon's "Naked DSL" announcement has some catches: http://www.techdirt.com/articles/20050419/1252202_F.shtml - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

New IPv6 allocations from IANA to RIPE NCC (2a00::/21) and ARIN (2600::/22, 2604::/22, 2608::/22, 260c::/22)
by Doug Barton 19 Apr '05

19 Apr '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, This is to inform you that the IANA has allocated the following one (1) IPv6 /21 block to RIPE NCC: 2A00:0000::/21 RIPE NCC And, the IANA has allocated the following four (4) IPv6 /22 blocks to ARIN: 2600:0000::/22 ARIN 2604:0000::/22 ARIN 2608:0000::/22 ARIN 260C:0000::/22 ARIN For a full list of IANA IPv6 allocations please see: <http://www.iana.org/assignments/ipv6-unicast-address-assignments> - -- Doug Barton General Manager, The Internet Assigned Numbers Authority -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD4DBQFCZWp/wtDPyTesBYwRAqWyAKCbj584cn15sQ4h67durCWPS/denQCVFSOM c0CXWpEMK4kmc6GcN6ak4Q== =Tjnd -----END PGP SIGNATURE-----

1 0

Ameritrade warns 200,000 clients of lost data
by Fergie (Paul Ferguson) 19 Apr '05

19 Apr '05

Gee, what a surprise -- another one: http://www.msnbc.msn.com/id/7561268/ Anyone wanna bet that tomorrow, this number will have grown "after further examination"...? - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

4 4

Re: Ameritrade warns 200,000 clients of lost data
by Fergie (Paul Ferguson) 19 Apr '05

19 Apr '05

Yes, mea culpa. Apologies.... - ferg -- Florian Weimer <fw(a)deneb.enyo.de> wrote: Isn't this slightly off-topic, even by NANOG standards?

1 0

Jonathan Yarden @ TechRepublic: Disable DNS caching on workstations
by Jay R. Ashworth 19 Apr '05

19 Apr '05

Here we go again... http://techrepublic.com.com/5100-10595-5657417.html?tag=nl.e044 My initial reaction is "why?" My followup reaction is "Well, most workstations don't cache anyway, do they?" Cheers, -- jra -- Jay R. Ashworth jra(a)baylink.com Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me

14 18

Re: Qwest protests SBC-AT&T merger as harmful to competition
by william(at)elan.net 19 Apr '05

19 Apr '05

On Tue, 19 Apr 2005, Alex Rubenstein wrote: > I am saying, "Who cars that Qwest is ticked off." Because Q is now ticked, > and fighting the fight that we want fought, this is _good_. That is certainly not bad, but I DO care who my allies. This has to do with how to rely on them. And for example I would not be surprised if Qwest statements only go so far as to serve their interest so they could negotiate their own piece of pie from MCI. So don't be astonished and cry "betrayed" if your "ally" Qwest and your "enemy" Verizon were to announce tomorrow a deal with Verizon keeping UUNET but selling off former WCOM CLEC portions to Qwest... >> Just wish the consumer had more input... Don't we all .... (and maybe we should do more then just wish, we do actually enjoy benefit of voting in this "democracy" that controls our lives...) -- William Leibzon Elan Networks william(a)elan.net

1 0

Re: cost of doing business
by Thomas Kernen 19 Apr '05

19 Apr '05

RE: cost of doing business That will not be the biggest issue since most of it is live TV hence multicast so that stream will be used by another customer anyway connected to the same customer termination device in the POP. Of course that will also be depended on the port density of the customer termination device. The real issue is VOD since each stream is a unicast stream per customer and that currently there is no valid implementation that allows one to actually reuse some of that unicast stream content to deliver to other users. Since most VOD is currently on a pay per view model customers should not be actually requesting those streams if not watching them, so for some time that will allow a certain "limitation" in the usage. Related to VOD and bandwidth usage there is some research carried out around the world to solve this issue and one of these solutions might be the "multicast patching", from what I've seen there is still a lot of work to be done before it can comply with an SP's network setup. The other unknown factor is that until now the customer has never had the choice of viewing what he wants when he wants so AFAIK there is no statistical model that exists in the video media field that allows to derive a mathematical model related to VOD consumption. Thomas ----- Original Message ----- From: Mike Macdonald To: Thomas Kernen ; nanog(a)nanog.org ; Andrew Odlyzko Sent: Tuesday, April 19, 2005 4:17 AM Subject: RE: cost of doing business The problem I see coming is simple bandwidth wastage driven by NA TV habits. Many homes have TVs on during the day full time even when not watched. Now were talking about as much as 10-20 Mbps (depending in HDTV adoption) going into a void. Mike -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Thomas Kernen Sent: Tuesday, April 19, 2005 1:48 AM To: nanog(a)nanog.org; Andrew Odlyzko Subject: Re: cost of doing business >> fwiw, 100mb to the home costs about that in japan > > > > We are talking of two different things here, traffic versus access > bandwidth. > It will be a while before the average household generates 5 megabit/s > traffic. > Even in Korea and Hong Kong, where the average broadband link is in > the 5-10 Mbps range, average traffic is about 0.1 Mbps. The main > purpose of high speed links is to get low transaction latency (as in > "I want that Web page on my screen NOW," or "I want that song for > transfer to my portable device NOW"), so utilizations are low. > For those of us that are already running triple play architectures and working on the data analysis related to the bandwidth usage growth (in my case over the last 18 months and adding services one after the other) I see this with a different light: I fully agree with the transaction latency syndrome, people are compulsive customers that want to buy right now and you (as a service provider) want to see to them purchase the service before they change their mind, just need to look at the ringtones market to see how much people are willing to spend within seconds for a piece of music they will replace in a few days/weeks with their next favorite tune from the charts that marketing is feeding them with. Where I don't agree is on the bandwidth usage analysis, once you add the IP based TV/VOD* services you will be carrying close to 5Mbps on average on your network in the near future. Either for the one of the TV channels (currently the market is talking about 2 concurrent TV channels down the same pipe to an end user's home in the North American model or 1 for the European) or the VOD. So agreed this is not Internet traffic but you will need to carry it beyond your access termination device (DSLAM/CMTS/ Ethernet switch) since the economics of the IPTV/VOD market and (current?) technical scalability will prevent you from being able to have a the full IPTV/VOD streaming (= unicast and/or multicast in this case) in each POP to keep the traffic as local as possible. So anyhow within your metro area network accessing and aggregating the customers the amount of bandwith required to service all customers will grow quite a bit with IPTV/VOD services. IMHO (of course) Thomas *Triple play IPTV/VOD = IP packets carrying a video signal using (name your favorite format) either as unicast or multicast stream. This excludes the current hybrid HFC networks that still provide digital TV via an HF stream using (insert your favorite standard here) and the Internet access and voice service over IP. Anyhow they will migrate once DOCSIS 3.0 and the wideband benefits have been marketed to all the cable operators as the "next big thing" they need to have and hence run an IP only service for all the triple play services.

2 3

Re: Verizon Offering Naked DSL in Northeast...
by Robert Bonomi 18 Apr '05

18 Apr '05

> Date: Mon, 18 Apr 2005 16:14:01 -0700 > From: Steve Sobol <sjsobol(a)JustThe.net> > To: North American Networking and Offtopic Gripes List <nanog(a)nanog.org> > Subject: Re: Verizon Offering Naked DSL in Northeast... > > > Andy Johnson wrote: > > > My speculation is that their billing/accounting system is based on a > > POTs number, and since these customers will not need one, they will have > > administrative errors managing accounts. > > Yeahbut. > > SBC was happy to assign me something that looks like a phone number, but > wasn't, so I could make monthly payments on a Yellow Pages ad a few years ago. > I was in area code 216, and the account number was 216 R01 XXX YYYY (I forget > what the rest of it was). > > So I'm not buying that argument. ;) "Speaking from experience" with Ameritech (pre-SBC, that is) in Illinois, *before* any form of "shared-line" DSL was available, the ILEC required a phone number _at_the_service_location_ -- for reasons of insuring that the DSL line was delivered to the "right place". (I don't know what they did if the phone belonged to a CLEC; I _do_ know that "no land-line service" caused all sorts of commotion.) There _is_ a reason for that -- particularly in larger multi-family buildings, there may be _more_than_one_ "service entrance" for that building. With different parts of the building reachable only from a given service entrance point. Thus, a need to ensure that the DSL is provisioned on the "right cable", going to the correct service entrance point. A "phone number" at the premises is something that the end-user _can_ reasonably be expected to know, and *does* "uniuqely identify" the path for service to reach that premises, *AND* can be reliably parsed by a computer. A 'street address' is considerably less reliable -- all sorts of inconsistant formats are used, user input may not match the structure in the database, etc., etc. Then you have the situation where a building may have multiple street addresses (e.g. a corner lot, and separate entrances), and the address for the 'service entrance' point is *not* the same as the service delivery address. There's a whole nother layer of database to rummage through, when there is no _existing_ service to a given location. One that is *not* -- at least anywhere near as easily -- amenable to automated 'validation' look-ups. It can be 'worked around', but it takes _manpower_ to do it. "people time" is _expensive_, vs machine time. I had an extended go-around on this with a DSL provider and the ILEC when I ordered DSL for a company employee who was using only a cell-phone -- no land- line service at all. The DSL provider computer wouldn't accept the order without a phone number -- so we gave it the landlord's number (the other side of the 2-flat). Then the ILEC computer wouldn't accept the order, because it _knew_ that there was no phone in service at that address. As I recall, this got escalated up the food chain, until a Sr. VP was talking to a Sr. VP, whereupon it _finally_ went through. The installers that came out (one from the ILEC to 'tag'/test the pair, and then the DSP provider guy to do the actual equipment hook-up) both remarked that they'd *never* seen an order like that one -- the 'premises phone number' read "000 000-0000". <grin> I suspect that the 'technical difficulties' that Verizon ran into, in implementation had to do with difficulties in _automating_ "address-based" queries into the physical plant database.

1 0

DSCP ECN bits
by christian.macnevin＠uk.bnpparibas.com 18 Apr '05

18 Apr '05

Hi, Is anyone using the DSCP ECN bits to any great extent? Does it require end-host support in the stack to actually work? Cheers, Christian This message and any attachments (the "message") is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. ********************************************************************************************** BNP Paribas Private Bank London Branch is authorised by CECEI & AMF and is regulated by the Financial Services Authority for the conduct of its investment business in the United Kingdom. BNP Paribas Securities Services London Branch is authorised by CECEI & AMF and is regulated by the Financial Services Authority for the conduct of its investment business in the United Kingdom. BNP Paribas Fund Services UK Limited is authorised and regulated by the Financial Services Authority.

2 1