- Test - lists.nanog.org

Re: Building a NOC
by Howard C. Berkowitz 21 Mar '98

21 Mar '98

At 14:51 -0500 3/16/98, Charles Sprickman wrote: >I think I'd disagree with that. Where would all you folks be if you never >picked up a book? You wouldn't be reading this list. Seriously, while >there's not an ORA "How to Build a NOC" book with some cute animal on the >cover, there is some information out there worth reading. > >I'd suggest digging through some telco info (if you'd like to consider a >CO a NOC). Also, there should be plenty of people on this list that >work in or have even designed decent sized NOCs. You can also cheat and >go browsing as a prospective customer at someplace like Exodus or any >other colo facility that is well-managed and modern. You can actually >learn quite a bit by just looking around... Excellent observation. There was a text, _Engineering and Operations in the Bell System_, that gave some good operational experience. With divestiture, I'm not sure who took it over. I vaguely remember that _Transmission Systems for Communications_ went to AT&T Bell Labs, and E&O went to Bellcore. I'd also consider looking through some of the military communications manuals. Unfortunately, I'm in the midst of a computer conversion and have to recover some bookmark files, but you can search for Army Field Manuals online -- they are at the TRADOC site at Ft. Monroe. > >Hopefully some of the startup NSPs will answer here, as the experience >should still be fresh in their minds... > >Charles > >~~~~~~~~~ ~~~~~~~~~~~ >Charles Sprickman Internet Channel >INCH System Administration Team (212)243-5200 >spork(a)inch.com access(a)inch.com > >On Mon, 16 Mar 1998, Martin Hannigan wrote: > >> Date: Mon, 16 Mar 1998 14:14:47 -0500 (EST) >> From: Martin Hannigan <hannigan(a)xcom.net> >> To: John_W_Connors(a)res.raytheon.com >> Cc: nanog(a)merit.edu >> Subject: Re: Building a NOC >> >> > >> > Would anyone have information or knowledge of books, WWW Sites, or other >> > means that would provide details on constructing a state of the art NOC to >> > support 75000+ nodes in a LAN/MAN/WAN environment >> > >> > Thanks in advance >> > JC >> > >> > >> > >> >> No books, it's all experience. >> >> >> Martin Hannigan V:617.500.0108 >> Director - Data Networks F:617.500.0002 >> XCOM Technologies, INC. hannigan(a)xcom.net >> Cambridge, MA http://www.xcom.net >>

1 0

Re: IP over SONET considered harmful?
by Sean M. Doran 21 Mar '98

21 Mar '98

| Native IP over fiber is not a religion; it's a solid engineering. I'm not totally convinced of this yet, because of the useful O&M and restoration facilities SDH/SONET buys you now. You need something underneath IP to do the sort of Lothberg restorations I think you saw explained at the last NANOG meeting. SDH/SONET is also a really keen way of sharing a network among IP and other things on the wide-area side, and an even keener way of having access to relatively low-speed customer data on the more local side. I agree with you that there is alot of unnecessary overhead in SDH/SONET, but there is also alot of what seems now to be necessary overhead, too. I do, however, expect heavy experimentation involving radical simplification of on-fibre framing for point-to-point paths dedicated exclusively to IP. Sean.

1 0

Re: IP over SONET considered harmful?
by Sean M. Doran 21 Mar '98

21 Mar '98

| Sounds reasonable to me. My point was that decrementing the IP TTL, | whether it be at each LSR or only at egress, should be a decision | that can be made by the provider. Sure, why not give ISPs the weapons with which to shoot themselves in the foot when their goals may be met in ways that are not quite so destructive? Tell them they are adults and REALLY shouldn't turn that knob, then give it to them. Works for me. --:) Sean. (mmm, two-router forwarding loop at line rate across a wide MPLS cloud, mmm)

1 0

Re: IP over SONET considered harmful?
by Sean M. Doran 21 Mar '98

21 Mar '98

| Not decrementing the IP TTL at each LSR hop no more breaks the | IP TTL mechanisms than does frame-relay or ATM. If this is the goal why not have a knob to generate an "appropriate" ICMP message when IP TTL is exceeded, where appropriate may mean "not relating to the MPLS infrastructure" or "none at all"? If people really really want to make sure IP ttl is decremented only by one no matter how many MPLS hops there have been, then they are obviously not worried about forwarding loops across a possibly very long (and consequently probably very expensive) MPLS cloud, and should not object to my earlier proposal for the configuration command. | ps. In fact, there may even be some ISP's that would prefer that | their internal L2 infrastructure remain invisible. These ISPs are wankers. Sean. (and that is the politest way I would put it)

2 1

Re: Internic hosage
by Dean Robb 21 Mar '98

21 Mar '98

At 22:59 3/18/98 -0800, you wrote: >For a good example of this, whois perhaps.youwant.to, then >nslookup perhaps.youwant.to. It looks like someone tried to pull >a Kashpureff that didn't really succeed. > >The nslookup version of perhaps.youwant.to came first, by the way. > >So what can we do to actually get something done about it? Anyone? Currently, I'm talking to a couple of people in the computer news world (one electronic, one electronic and print) about doing a nice expose-style article. Seems that we should be getting SOMETHING for our $100, no? [snip...] I forgot to mention that I've been in contact with Bode & Biddle as well; the firm sueing NSI over the registration fee. Seems that NSI's stance (including email from NSI that specifically says they won't delete a domain unless they don't pay) fits in nicely with the argument that NSI is a "money-grubbing monopoly". Spam: it's not just for breakfast anymore.... Dean Robb PC-Easy On-site computer services (757) 495-EASY [3279]

2 3

IP over SONET considered harmful?
by Alan Hannan 21 Mar '98

21 Mar '98

Subject: IP over SONET considered harmful? Perhaps. I am concerned about the growing movement towards IP over SONET. Previously in my career I was a vocal advocate of IP over ATM for several reasons, primarily traffic engineering and statistical gathering ability (obvdisclaimer, this required an autonomous unshared network used only by the ip provider for interhub traffic). However, I am firmly rooted in the bandwagon advocating IP OVER SONET FOR EVERYONE. Firmly. Accordingly, I am concerned about the visible L3 hop inherent to packets transiting routers. An ATM core is, of course, invisible to L3; so the number of switches or hubs through which a packet travels is inconsequential to the TTL of the packet. When a backbone is constructed with a PACKET over SONET core, the packet is likely to decrement the TTL by 2 at every hop. The number 2 is assumed because you are likely to leave from a router different than the one you come in. Since I tend to think in formulas, I'll encourage you to do so as well. Variable Meaning -------------- --------------- ROUTER L3 device which decrements the ttl of an IP packet TRANSIT_HUBS The number of hubs which neither sources nor delivers the packet NONCOREROUTERS The number of routers which accept or deliver traffic to a peer or customer TRANSIT_ROUTER A router which transits the packet TTL_DECREMENTS The number of ttl counters which this network decrements Assuming an architecture with dual core routers and two layers of hierarchy (backbone v. customer aggregation/peering), I believe the following formulae dictate the TTL degredation expected: ATM NETWORK: ----------- TTL_DECREMENTS == (NONCOREROUTERS + TRANSIT_ROUTERS) * 2 IP NETWORK: ---------- TTL_DECREMENTS == (NONCOREROUTERS + TRANSIT_ROUTERS) * 2 + TRANSIT_HUBS * 2 Another assertion I would make is that a 'responsible' NSP should decrement no more than 1/4 of the TTLs in the least common denominator. This follows from a general assumption of 2 NSPs, and 2 Customers; hence 4 entities. I consider Windows 95 to be the least common denominator, which has a default IP TTL of 32. Yes, 32. So that implies that each NSP should decrement no less than 8 TTLs. Solving IP NETWORK for TTL_DECREMENTS=8 implies that a network can have a diameter of no more than 4 hubs. That's a pretty meshed network when you have more than a few hubs. Does anyone have any strong opinions or sources on this matter to alleve my fears? The only solution I see is to fix mswindows; but of course that is quite difficult. I'd hoped that MPLS would solve this problem, but from reviewing the drafts I believe that the LSRs _WILL_ decrement the TTL. Your comments appreciated. -alan

7 7

Re: IP over SONET considered harmful?
by Vadim Antonov 21 Mar '98

21 Mar '98

It is one thing to design a network for something which takes 30% of traffic. It is quite another to add new layer of complexity for something which is going to be less than 1% of traffic in few years. Native IP over fiber is not a religion; it's a solid engineering. And you never _have to_ have synchronous circuits to provide service to end users. The brainwashed IT managers who equate voice with synchronous transmission or resource reservation are entirely different breed. Of course, the history is full of examples of people getting rich selling snake oil. Unfortunately that business never lasts long. OSI and VLAN yesterday, CBR today, multicast and IPv6 tomorrow. Right, yeah. I'm not try to tell that there aren't any broken-as-designed legacy junk which one has to deal with time to time; but doing any sensible design for the future means that some old stuff just not going to work anymore. --vadim Stan Hanks <stan(a)networkmercenaries.com> wrote: >As great as POS is, and as exciting as running IP on optical OC-48 onto WDM >gear sounds (no piece of cake, believe me...), there is STILL room for >ATM. More than just the much-touted network traffic engineering value, too. >Simply put, because of the B-ISDN heritage of ATM, I can actually run >synchronous circuits over it (using circuit emulation) and have it work right. >Can't get there from here with any IP-over-glass solutions, alas. >And as much as an "IP over everything" bigot as I've been for the last >17 years or so, I still run into situations where what I *HAVE* to >have is some kind of synchronous circuit. Wish it weren't so, but I can't >just tell people "oh, you can't do that"...

1 0

Re: Internic hosage (fwd)
by Dean Robb 21 Mar '98

21 Mar '98

At 02:07 3/21/98 +0500, Eric Eden wrote: > >Hosts ending in .TO can be listed in our database because >ISO 3166 hosts may be serving COM, NET or ORG domain names. > >In this case we removed the host and notified the contact of the >host because it is not currently serving any domain names or >networks in our database. Most excellent. Now, what would you have done if it was Dirtbag.com that had provided the false information? Spam: it's not just for breakfast anymore.... Dean Robb PC-Easy On-site computer services (757) 495-EASY [3279]

1 0

Re: IP over SONET considered harmful?
by Kent W. England 21 Mar '98

21 Mar '98

> >(b) talk to your favorite vendor(s), and ask the vendor(s) to put > a "knob" that would decrement IP TTL by 1 on egress (rather > than copying Tag TTL into IP TTL). > >Yakov. > Yakov; As I recall, the world didn't end when the NSFNET NSSs were installed and they decremented TTL twice. Weren't they changed to decrement once, appearing as one instead of two routers? (For those who don't remember the NSFNET "routers" they consisted of an IBM RS6000 attached to each of several T1/T3 interfaces, interconnected across a FDDI with a route server. Nine RS6000s in all. 200 amp service required. :-) This is no reason to raise a harmful alarm. --Kent

5 4

Re: Internic hosage (fwd)
by Dean Robb 20 Mar '98

20 Mar '98

At 15:21 3/19/98 -0500, Eric Eden wrote: > >You're right, that's an interesting question. However, >validating the requests to create hosts within ISO 3166 >domain names is a difficult issue. Each ISO 3166 registry >has different registration look-up systems and we have >little or no information to gain authentication for >creation or updates to these hosts. > >How would you recommend that we interface with the 240 >ISO 3166 registries around the world to authenticate >these requests in a cost effective manner? I don't >think ns lookup queries do not provide a robust solution - >specifically with authentication. > >I agree with your point. We haven't been able to define >a workable solution for this problem. We welcome any >input you have. The easiest thing in the world; already proposed weeks ago (now months ago) for WhoIs in general [using the specified problem as example]: 1. Users spot errors (Dal saw that the IPs for youwant.to were wrong). 2. Users send an email to InterNIC regarding errors, including methodology and other resources used to discover that the info was erroneous. 3. InterNIC verifies information provided in email (look at WhoIs, verify that the methodology was sound, etc.) 4. If the information is clearly a lie (such as a phone number of 555-1212), InterNIC deletes the domain (as provided in para L of the Registration Agreement). If the information might be an error (transposed numbers in IP), InterNIC sends an email (again, as provided in the Registration Agreement) requesting clarification. 4a. If the domain does not reply with the 30 days mentioned in the Registration Agreement, or if the email bounces, the domain is deleted. 5. Problem solved, database corrected, slimeball taken down. 5a. In the event of an erroneous deletion, the domain is simply reinstated. 5b. If the slimeball liar wants to re-register, he/she/it pays another $100. A simple, cost-effective solution to the problem. No new hardware needed. No new software needed. POSSIBLY a single employee needed (although since the problem is self-diminishing, using an existing employee would probably work fine). According to the July 97 IPO filing with the SEC, NSI earned a net profit of $391,688 Jan-Mar 97 from domain registrations, so there's no cost barrier to the solution. Now...why can't this be done? Spam: it's not just for breakfast anymore.... Dean Robb PC-Easy On-site computer services (757) 495-EASY [3279]

1 0