- NZNOG - lists.nznog.org

Transfer of management now complete
by Elly Tawhai 03 Jul '05

03 Jul '05

Hi, Transfer of historical IP address ranges ---------------------------------------- The following address ranges were transferred from NZTelecom to APNIC's management on 1 July 2005: 202.27/16 202.37/16 202.36/16 202.49/16 202.50/16 For more information about how to update your resources, please refer to section 4 of "Historical resource policies" at: http://www.apnic.net/docs/policy/historical-resource-policies.html#4 If you have further queries, please feel free to contact APNIC at: <helpdesk(a)apnic.net> Regards, APNIC Secretariat

1 0

Another Technical Announcement
by Richard Naylor 03 Jul '05

03 Jul '05

Wearing my R2 hat.... R2 has recently installed a streaming media server at the Palmerston North (PNIX) internet exchange in addition to servers already at WIX and APE. We also have a server located in California, USA to serve content to New Zealanders overseas. These have been tested during the current Lions Rugby tour and are now fully operational. They will shortly be carrying the previously announced RNZ service. This announcement is to advise that all the streams carried by R2 on behalf of Rhema Broadcasting Group (RBG) are now available on all servers. These streams are Radio Rhema www.rhema.co.nz Southern Star www.sstar.co.nz LifeFM www.lifefm.co.nz ShineTV www.shinetv.co.nz The audio streams are available in bit rates up to 64kbps and TV up to 384kbps. We expect to make a 2Mbps TV stream available by the end of the month. Details of the streams is available via the station websites listed above. RBG content is both live streams and on-demand content. We have chosen to deploy a multi-homed architecture for the following reasons: 1. Greater diversity and redundancy than a single site/provider architecture. 2. Reduced network latency for improved streaming performance. 3. Shortest path for broadband consumers (reducing network congestion for Operators). 4. Scalability, allowing us to add servers at new exchanges in the future. 5. To minimise national transit costs for the ISP's of customers using the content. 6. Lowest cost to serve content. 7. Ability to better serve international viewers and listeners of NZ stations. The servers have a globally consistent anycast IP address which is advertised at each exchange to ensure that the content is delivered from the nearest server to the consumer. In order to get the best performance we recommend that you peer directly with the anycast routers at all the exchanges where you have connectivity. Any peering questions should be directed to me at richard.naylor(a)r2.co.nz Thanks Richard

1 1

Re: [nznog] Archived stream of this morning's Nat Radio programme(s)
by Webmaster 03 Jul '05

03 Jul '05

There is a long standing caching (as I understand it) problem. If you press reload/refresh a couple of time it clears the error. cheers, Richard Hulse >>> Dan Clark <dan(a)synaptic.net.nz> 4/07/2005 11:35 >>> used to be http://www.radionz.co.nz/audio I think, for some reason it go's to some broken Telecom Xtra link. Dan Juha Saarinen wrote: > Is there one somewhere? RadioNZ? R2? > _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

Archived stream of this morning's Nat Radio programme(s)
by Juha Saarinen 03 Jul '05

03 Jul '05

Is there one somewhere? RadioNZ? R2? -- Juha

2 2

Notification of NZRR Database changes
by NZRR Database Notifications 03 Jul '05

03 Jul '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: aut-num: AS24385 as-name: NZRR-AS24385 descr: 3CIX admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS64646 accept ANY AND NOT {0.0.0.0/0} AND NOT fltr-bogons export: to AS64646 announce ANY AND NOT {0.0.0.0/0} AND NOT fltr-bogons notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050701 source: NZRR REPLACED BY: aut-num: AS24385 as-name: NZRR-AS24385 descr: 3CIX admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS64646 accept ANY AND NOT {0.0.0.0/0} AND NOT fltr-bogons export: to AS64646 announce AS24385:RS-ROUTES AND NOT {0.0.0.0/0} AND NOT fltr-bogons notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050701 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 03 Jul '05

03 Jul '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: aut-num: AS24385 as-name: NZRR-AS24385 descr: 3CIX admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS64646 accept ANY export: to AS64646 announce AS24385:RS-ROUTES AND NOT {0.0.0.0/0} AND NOT fltr-bogons notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050701 source: NZRR REPLACED BY: aut-num: AS24385 as-name: NZRR-AS24385 descr: 3CIX admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS64646 accept ANY AND NOT {0.0.0.0/0} AND NOT fltr-bogons export: to AS64646 announce ANY AND NOT {0.0.0.0/0} AND NOT fltr-bogons notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050701 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 30 Jun '05

30 Jun '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: aut-num: AS24385 as-name: NZRR-AS24385 descr: Smartlinx3 descr: WIX peering at '202.7.1.20' descr: see Citylink RT job #2729 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS24385 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050701 source: NZRR REPLACED BY: aut-num: AS24385 as-name: NZRR-AS24385 descr: 3CIX admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS64646 accept ANY export: to AS64646 announce AS24385:RS-ROUTES AND NOT {0.0.0.0/0} AND NOT fltr-bogons notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050701 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 30 Jun '05

30 Jun '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- OBJECT BELOW DELETED: route-set: AS9439:RS-ROUTES:AS24385 descr: Route set advertised to AS9439 by Smartlinx3 - AS24385 members: 218.100.26.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050701 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 30 Jun '05

30 Jun '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- OBJECT BELOW CREATED: route-set: AS9439:RS-ROUTES:AS24385 descr: Route set advertised to AS9439 by Smartlinx3 - AS24385 members: 218.100.26.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050701 source: NZRR

1 0

Re: [nznog] Technical Announcement
by Richard Naylor 30 Jun '05

30 Jun '05

At 10:14 PM 6/29/2005 +1200, Simon Lyall wrote: >On Wed, 29 Jun 2005, Jamie Baddeley wrote: > > Have you considered multicast as an option, and if so, what stopped you > > from deploying it? Client support or Network support? > >Does anyone have full end to end support of multicast? I would guess with >bitstream and people having layer-2 all the way it might be possible to >do it these days. In a pure L2 network multicast is a dangerous technology. Think of what happens to a 10meg user when a 100meg user kicks off a 25meg multicast stream. The trend seems to be to use multicast inside tunnels in this environment. Thats the way the Access Grid folks are going. It also allows user groups within a network to opt in and out of multicast sessions. Theres quite a few tunnels tools around. >Not sure what it would be any practical use for though. Lots of chickens >and eggs here. yes. A few "broken network" days ahead. Multicast is good for synchronous events - like TV watching or LOTR Premieres etc. But for asynchronous events - like day to day watching of video, which is tending towards "on-demand", then multicast has almost no value. With the usual availability of bandwidth, I feel multicast is going to be of declining importance but will be implemented more for niche applications, which will become more important in themselves. The "tv" world is fascinated by "video on demand" and the radio (Audio) world is fascinated by Podcasting (aka on-demand listening - mobile). Neither of these is aided by multicast and in themselves they don't impose huge demands on both servers and networks. What we do know is 50x 2meg streams doesn't require 100Mbps. The technology certainly doesn't work that way - the playout buffer is your friend. So unicast streams are not overly heavy on the network or the server. Having said all that, we will be playing with multicast and probably making it available. The other thing we'll be playing with is better quality and alternate compressions. We're very close to be able to originate those nice HD streams we demo'd last year. So maybe NZNOG-06 will be in 10Mbps HD streams....... Rich

2 1