- Test - lists.nanog.org

ONS - slightly OT offlist if you care to comment.
by Chiloé Temuco 17 Aug '07

17 Aug '07

My opinion: A tier 1 provider does not care what traffic it carries. That is all a function of the application not the network. A tier 2 provider may do traffic shaping, etc. A tier 3 provider may decide to block traffic paterns. ------------------------------ More or less... The network was intended to move data from one machine to another... The less manipulation in the middle the better... No manipulation of the payload is the name of the game. That being said. It's entirely a function of the application to timeout and drop out of order packets, etc. ONS is designed around this principle. In streaming data... often it is better to get bad or missing data than to try and put out of order or bad data in the buffer... A good example is digital over-the-air tv... If you didn't build in enough error correction... then you'll have digital breakup, etc. It is impossible to recover any of that data. If reliable transport of data is required... That is a function of the application. ------------------------------ a tier 1 can never not have enough capacity.. always N+1.... 99.999% a tier 2 can afford 95.0% a tier 3 75% or better is a good target. wireless i call tier 4 - 50% is a good target... there are too many variables for ANY type of SOA. Just because you got the data... doesn't mean it wasn't re-requested 20 times. 256^6 AS : Network : Subnet : Machines We will never run out of IP space... IPv6 is too dificult to understand... ONS is a direct replacement for the ENTIRE network architecture. Sonet, etc... It's all replaced. So you all get it from an address AS : NETWORK : SUB-NET : MACHINE [MAC] 04.43.AA.AA.00.01 : 00.00.32.AA.00.F2 : 54.23.AA.43.AA.00 : 90.FA.A0.A9.F3.C2 The address includes everything about your network address... AS to MAC address... That is networking made simple... And the routing and AS to AS mechanism is that much simpler.... MPLS switching is a good way to think of it. I provide a path to your AS... at entry you provide a path to it's destination. Or onward to the next connected AS. SO something similiar to BGP is your inter-AS protocol for establishing what is where... It's entirely interface driven... I just provide the next interface... Each routing- switch is a node... So the list just tells it the node numbers to traverse... calculated at entry to your AS.... node : interface : subinterface . sub [AS] : 08fa.003a : 0002 : 0000.00 Of course a DNS naming convention is implementable... Who wants to think of every single device as a number w/o a name.... Node / interface address... You could prepend the AS at the begining.. but I would strip it from what people see ... Of course you could to MPLS type as to as routing... but that table could become huge.. and it's typically best for each provider to decide what to do with the traffic at entry to it's network... perhaps only for your own customers would you do MPLS / MPLS type peering. ------------------------------ It's like I'd peer a maximum of 4 x OC192 to another tier-1 and everything else for their network either gets dropped or they pay for additional bandwidth... I peer ONLY with tier-1 providers... a maximum of p GB/s... Everything else is paid traffic. I have confidence that my network is directly connected to 85% of the world... And that my datacenters and distribution network cary 85% of the traffic neccesary. ------------------------------ Every customer looks like a subnet... They can attach a virtually unlimited number of devices to their subnet... ------------------------------ That is to say that a sonet ring is made up of a series of devices... The entire network is ONS... Every single device on it. Hybrid-switching... It's still early in the design stages... Designed but not implemented. ------------------------------ Now which university wants to give me my degree??? How about that CCDP??? ------------------------------ What a packet / frame / whatever looks like: [AS Path] : [QOS identifier] : [Switching path] : [destination address] : [control bits (stack)] : [origin address] :[payload] : [padding] [AS]: prepended at network entry... validating this belongs on my network. important if your a transit point between two AS's. and your network doesn't appear in the origin or destination... could even contain the AS and other information about how it got there... netflow stuff... could just be an AS path... but it's best to let the next network decide what to do with it... It's just good to know this belongs on this network and this is why it's here... a. it originated here b. i accepted it from AS x as customer c. i accepted it from ASx a peer d. gateway of last resort e. other If it shows up on another AS... it will know that the data requires validation / handling ... so when i give it to AS p on interface g that machine will have to validate it belongs there and change the AS to indicate it belongs and calculate a path. Deffinetly an AS path to ensure that I don't just give it right back to the origin AS or anywhere else that has already had it because I think you have a better path to it. So it MUST retain the AS's that it has traveresed. Prevent routing loops. If I receive something from an AS that I'm not supposed to receive from... Either accept it due to policy override. Or drop it and create an alarm. Either way create an event. QOS: first .. drop it unless i have to have it in congestion. queue everything else.... typical QOS stuff. I don't even want to process it if I'm congested or overloaded unless it is X priority. switching path: node:int:sub//node:int:sub//node:int:sub//node:int:sub....[padding] .... end of path. each node strips it's address and moves it to the next interface. [QOS identifier] - 00.00 default. no priority. so a QOS enabled network would be able to buffer data and manipulate it... a tier 1 should have enough capacity to never need this. especially at 100+ gb/s ... a tier 3 or tier 4 network... this could be useful... at congestion... just drop the data unless it is FF.xx could be used like FECN / BECN... I'm congested at the end... quench everything that isn't important. store it if it's EE drop anything less... FF must reach it's destination. if something bad happens it looks up the origin address and returns some sort of message indicating it's node address ... [control bits] undefined... containing an application identifier, sequence number, data type, crc, crc version, etc. what we once called a socket number.... packet , etc... ff.00 even the application could be switched to a particular computing node... / interface special address... saying that a cluster is a subnet and some control device decides where what goes... A RFC would be neccesary for the worlds input in assuring a versitile protocol that will not ever need to be updated... Devices on the network would obviously all require address... AS : FF.FF.FF.FF.FF.FF this network only... and some sort of addressing... too be determined. You'd also want some sort of encryption alogrythm on control data to ensure no one has slipped you a roofy. I suppose just utilizing the switching path to get it where it needs to go... special addresses, etc... anything bound for all FF's has to be for me... better authenticate it. the application sees the control bits, origin, payload] anycasting still works... one network number is a special number... always anycast... you can have as many subnets under that as you like... so at entry the path to the closest / best node is chosen... if those nodes are doing anything that requires always getting the same node ... then they had better have some application level magic happening... static interface scratch files.... something like that.. 1kb of data FF.FFalways going to the control node... keeping track of what is where. so you received a request that you don't know what to do with.. better consult the control node. (c) 2007; Patent Pending Chile and other territories. I intend to license it like the drug companies... ------------------------------ Finished! Enough to get started with an implementation. A few important things... Max AS path... after x it's automatically dropped. Max Switching path... I only reserved so many bytes... Target size 32768 bytes with 16384 bytes data. fully adjustable based on experimentation. So this is saying that for whatever reason I have decided this must go to AS x... Now you decide what to do with. But don't EVER give it back to me.

8 13

Anyone seeing ongoing issues with AOL?
by Howard Leadmon 17 Aug '07

17 Aug '07

Anyone else seeing ongoing issues with AOL? I started having users badger me about not being able to reach our video site about 3 days ago. With traces out, I am seeing in the range of 50% packet losses when I get into AOL. I tried this from both my Cogent, and another location where we have a link going via Telia. Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 14. aol-114080-ldn-b2.telia.net 0.0% 100 94.9 103.9 94.0 159.4 9.6 15. aol-114080-ldn-b2.telia.net 0.0% 100 103.3 97.8 92.8 134.3 7.0 16. bb2-loh-S1-1-0.atdn.net 0.0% 100 94.6 97.9 93.1 149.4 8.1 17. accessl1-los-S0-3-0.atdn.net 0.0% 100 95.8 96.7 92.8 120.9 3.8 18. accessl1-los-S0-1-0.atdn.net 51.5% 100 95.5 96.5 92.9 125.5 4.9 19. rt-lostb06.proxy.aol.com 51.0% 100 93.6 96.3 93.6 116.1 4.1 Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 3. v3489.mpd01.dca02.atlas.cogentco 0.0% 100 0.9 9.3 0.8 205.3 29.9 4. v3494.mpd01.iad01.atlas.cogentco 0.0% 100 9.5 16.6 1.1 191.9 34.1 5. verio.iad01.atlas.cogentco.com 27.0% 100 1.0 1.5 0.9 12.3 1.9 6. pop2-ash-S2-1-1.atdn.net 23.2% 100 1.1 2.3 1.0 25.1 3.9 7. bb2-ash-P2-0.atdn.net 24.0% 100 1.1 17.8 0.9 192.6 42.7 8. bb1-nye-P3-0.atdn.net 20.0% 100 6.6 20.8 6.4 212.3 44.2 9. bb1-loh-S1-2-0.atdn.net 28.3% 100 81.8 83.1 81.6 100.8 4.3 10. pop1-loh-S1-0-0.atdn.net 28.0% 100 77.3 79.3 77.2 98.5 2.8 11. accessl1-los-S0-1-0.atdn.net 22.2% 100 81.9 81.6 79.5 90.7 2.7 Find it hard to believe this is killing us, and not affecting a lot of others, but I haven't seen any chatter on list about it.. --- Howard Leadmon

1 0

Mailing list policy broken..
by Paul Ferguson 17 Aug '07

17 Aug '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If I subscribe to the mailing list, and the "-post" mailing un-blocker, there should be NO reason my e-mails should be blocked to the NANOG list. Right? I mean, that's kinda the whole point, right? Can someone please fix this? This is broken, broken, broken. I shouldn't get messages like these: [snip] <nanog(a)nanog.org>: 198.108.95.8 does not like recipient. Remote host said: 550 <nanog(a)nanog.org>... Relaying denied Giving up on 198.108.95.8. [snip] - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.2 (Build 2014) wj8DBQFGxSJbq1pz9mNUZTMRAp/6AKCsLbANou0lo2aBX0wRjzrUKm3YVwCcD7bM twZrVzkJp+Q5lepVT/LIyuc= =RWSo -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

Re: ONS - The few the proud ... the sleeping
by Valdis.Kletnieks＠vt.edu 17 Aug '07

17 Aug '07

On Thu, 16 Aug 2007 18:12:15 -0000, bmanning(a)vacation.karoshi.com said: > On Thu, Aug 16, 2007 at 10:02:02AM -0400, Jeff Aitken wrote: > > We could go stand on the roof of either 8100 Boone or 1919 Gallows and > > throw something off (maybe an old 7507). Would that count? > nope... terminal velocity is not what we are after here... > looking for more thrust :) Hmm... what hardware upgrades would make a 7507 rfc1925, section 2.3 compliant?

1 0

nanog list bad sub
by Randy Bush 16 Aug '07

16 Aug '07

the following post should not have come to me

2 2

Preliminary agenda for NANOG 41
by Steve Feldman 16 Aug '07

16 Aug '07

The following talks have been accepted so far for the NANOG 41 conference, to be held October 14-16 in Albuquerque, NM: General Session: Perfect Storms, Internet Economics, and the Future of the Internet - David Meyer, Cisco/Univ. of Oregon IPv6 Transition & Operational Reality - Randy Bush, IIJ From NetFlow to IPFIX: the evolution of IP flow information export - Brian Trammell, CERT/NetSA; Elisa Boschi, Hitachi Europe Resilient L2 VPNs - Ian Cowburn, Alcatel-Lucent Have We Reached 1000 Prefixes Yet?: A snapshot of the global IPv6 routing table - Gert D�ring, SpaceNet AG, presented by CJ Aronson Protection and Fault Recovery at Internet Peering Points using 802.1ag CFM - Rahul Vir, Foundry Networks Integrating Networks - Nina Bargisen and Michael Lyngb�l, TDC Research Forum: BGP Protection Without Global Cooperation - Josh Karlin, University of New Mexico and Stephanie Forrest, University of New Mexico and Jennifer Rexford, Princeton University Tutorial: BGP Multihoming Techniques - Philip Smith, Cisco Systems Layer 3 VPN for v4 & v6 in IP Core - Madhusudan Nanjanagud, Cisco Systems BOF: Peering BOF XVI - Bill Norton, Equinix On Sunday, October 14, there will also be a special one-day workshop on IPv6 implementation, jointly sponsored by NANOG and ARIN. The week continues with the ARIN XX meeting on October 17-19. A preliminary overview of the agenda looks like: SUNDAY, October 14 - Joint NANOG/ARIN IPv6 Workshop - all day - Registration - TBA - Tutorials: 1:30pm - 5:00pm - Newcomers meeting and reception - TBA - Community meeting - TBA MONDAY, October 15 - Registration - all day - Contintental beakfast - 8:00 - 9:00 - General session - 9:00 - 12:30 - Lunch (on your own) - 12:30 - 2:00 - General session and/or BOFs - 2:00 - 5:30 - Beer 'n Gear - 5:30 - 7:30 Tuesday, October 16 - Registration - all day - Contintental beakfast - 8:00 - 9:00 - General session - 9:00 - 12:00 - Lunch (on your own) - 12:00 - 1:30 - General session - 1:30 - 5:00 These times are tentative, and subject to change as the agenda firms up. Finally, a few announcements from Merit: Meeting registration <https://www.nanog.org/registration/> is open and the lower registration rate is in effect through September 24. The group room rate at the hotel <http://www.nanog.org/mtg-0710/hotel.html> expires September 24. Note: make your reservation 'early' as NANOG is meeting on the tail end of the ABQ International Balloon Fiesta. Hotel rooms will be in high demand, especially on Saturday night, Oct. 13. For additional meeting information, please see <http://www.nanog.org/>. See you in Albequerque! Steve Feldman PC Chair

1 0

DNS not working
by leeyao＠trashymail.com 16 Aug '07

16 Aug '07

Hi, I try adding google.com to my dns server to get more visitors but google.com still show search engine. Please advise how to do so more visitor in return? May the Gods be with you!

1 0

RE: Network Inventory Tool
by James Fogg 16 Aug '07

16 Aug '07

> From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Wguisa71 > Sent: Monday, August 13, 2007 11:31 PM > To: NANOG > Subject: Network Inventory Tool > > > Guys, > > Does anyone known some tool for network documentation with: > > - inventory (cards, serial numbers, manufactor...) > - documentation (configurations, software version control, etc) > - topology building (L2, L3.. connections, layer control, ...) > > All-in-one solution and It don't need to be free. I'm just looking > for some thing to control the equipments we have like routers > from some sort of suppliers, etc... > > Marcio Opsware Network Automation System does an excellent job. Not free. It also handles configuration management, software management, compliance, configuration policy management and other needs.

2 1

Re: [policy] When Tech Meets Policy...
by Paul Ferguson 16 Aug '07

16 Aug '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I was just struck by a couple of statistics: [snip] In January 2007, according to PIR five registrars deleted 1,773,910 domain names during the grace period and retained 10,862. That same month, VeriSign reported that among top ten registrars, 95% of all deleted .COM and .Net domain names were the result of domain tasting. [snip] http://www.informationweek.com/management/showArticle.jhtml?articleID=20150 0223 Having said that, Jay Westerdal mentioned on Sunday that: [snip] Today was the largest Domain Tasting day ever. We recorded over 8 Million Transactions today. This is a new high. We have never seen 8 Million transactions on one day before. That would be either an add or delete. Over 99 percent of these transactions are completely free and use the 5 day grace period to test domain names for traffic before they are purchase for a long term buy. [snip] http://blog.domaintools.com/2007/08/biggest-domain-tasting-day-ever/ Although I'm not sure all of that 8M+ were actual "tasted", it does represent an astronomical number of registrations. Just a couple of data points. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.2 (Build 2014) wj8DBQFGwPUBq1pz9mNUZTMRAlumAKD6t0AQS050YRaaxCqYomMWPDP6NgCgmSFO Frvz42ZtnHXYaRQ8hgXK4LA= =bvP6 -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

6 6

Re: Extreme congestion (was Re: inter-domain link recovery)
by Stephen Wilcox 16 Aug '07

16 Aug '07

On Wed, Aug 15, 2007 at 12:58:48PM -0700, Tony Li wrote: > > On Aug 15, 2007, at 9:12 AM, Stephen Wilcox wrote: > > >>Remember the end-to-end principle. IP backbones don't fail with > >>extreme > >>congestion, IP applications fail with extreme congestion. > > > >Hmm I'm not sure about that... a 100% full link dropping packets > >causes many problems: > >[...] > >L3: BGP sessions drop, OSPF hellos are lost.. routing fails > >L2: STP packets dropped.. switching fails > > > It should be noted that well designed equipment will prioritize > control data both on xmit and receive so that under extreme > congestion situations, these symptoms do not occur. Hi Tony, s/will/should/ The various bits of kit I've played with have tended not to cope under a massively maxed out circuit (I dont mean just full, I mean trying to get double the capacity into a link). This includes Cisco and Foundry kit.. not sure with other vendors such as Extreme or Juniper. Often the congestion/flaps causes high CPU, which also can cause failure of protocols on the control plane. Also, if you have something like router-switch-router it may be that the intermediate device looks after its control plane (ie STP) but for example sees BGP as just another TCP stream which it cannot differentiate. Whilst it may be that control plane priority, cpu protection are features now available.. they have not always been and I'm fairly sure are not available across all platforms and software now. And as we know, the majority of the Internet does not run the latest high end kit and software.. Steve

1 0