March 1998 - Test - lists.nanog.org

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

22 Mar '98

Scott Brim wrote: | For example, in order for TTL to be effective, not every node needs to | decrement it -- we just need to be sure that no loops can form where it | doesn't get decremented. Yes, but you also want to make sure that the price-per-packet is really really really close to zero in the "gap" between ttl decrementing routers, otherwise, even though a loop may never form in the non-ttl-decrementing fabric, it may form across it, for example, between the two routers on either side of the gap, or through the two routers on either side of the gap. If the "gap" is a sub-IP fabric a continent and an ocean wide, such a loop tends to be somewhat expensive. TTL decrementing as a loop mitigation feature ought to be fairly popular in such circumstances. Sean.

1 0

Re: Building a NOC
by shields＠crosslink.net 22 Mar '98

22 Mar '98

In article <v03007825b13a859bc617(a)[168.143.1.215]>, "Howard C. Berkowitz" <hcb(a)clark.net> wrote: > Of course, the bridge of the NCC-1701 series Enterprise(s) here show > incredibly bad human factors design, but that is often ignored. Perhaps > more realistic is the display over the medical bed. While one of the bar > graphs has text too small to read on the TV screen, the Star Trek technical > manual shows how it is labeled "Medical Insurance Remaining." > > Surely there is a NOC equivalent of that bar graph. "Venture Capital Remaining"? -- Shields, CrossLink.

1 0

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 20 Mar '98

20 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 20 Mar '98

20 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 20 Mar '98

20 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 20 Mar '98

20 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