- Test - lists.nanog.org

Re: too many routes
by Sean M. Doran 14 Sep '97

14 Sep '97

Alan Hannan <hannan(a)bythetrees.com> writes: > > Sprint recently announced that they are deploying 622Mbps > > POS cross-country links, and the GSRs are the only things > > you can put on the ends of such beasts that are available > > today. > > This is untrue. Other people have pointed out that the statement is perfectly true, but we can ignore the semantic misunderstanding. AFAICT there is only one orderable, deployable and tested IP router which observably terminates multiple 622-Mbit/s bit pipes, notably that made by cisco. One thing I find amusing is your own company's recent heavy investment in cisco's only likely competitor. Maybe this will mean cisco will stop paying so much attention to the ridiculous requirements UUWHO coughs up because it insists on a heavily meshed architechture for what has since become essentially purely political reasons, and start paying attention to people who are building sensible hierarchical networks that display much better scaling properties on nearly all fronts. (I hope so). Maybe this will also make people shy about helping Juniper because that translates directly into helping UUWHO as well. Who knows, maybe such things aren't so important, especially since the cisco product a/ works and b/ is *cheap*. > These can be disaggregated into OC3 ATM pipes that can be fed into > many routers with proven technology and reliability. Granted, the > disproportionality of the edge ckts to the backbone ckts provides > for interesting flow aggregation dynamics, but it does work. Oh sure it works if you turn LS IGPs on their head and try to avoid thinking too hard about how to build spanning trees without building a physical VC topology for multicast and can put up with interesting buffering and switching effects and, as you say, the dynamics of WHY it works vs. why it doesn't work when things break. I hate to say it but I think I have become old and this might explain why I like really simple and straightforward failure modes. > Your disdain for ATM does not stop its existence and use by the > larger NSPs. Technical merit has only been offered up as a reason for using cells by your organization and ATMNET, AFAIK. Everyone else who has been using ATM has done so because it was one of only three obvious scaling paths, with the other two being also gross (large numbers of parallel DS3s using load-balancing and flattening the network with lots of DS3s resembling lots of VCs, which is essentially what UUNET did with its physical topology anyway). > Aggressive statement, though the timbre is occasionally marked by > usefulness. I wonder how the world would develop without Sean's > input..... {music, clouds, harps... visions of ATM faeries > dancing with sugarplums...} Hahah. Well, don't forget the Russian and the Swede who also sang from the same songbook, and the other congregation members who were at NANOG meetings when everyone was angry at the BELLCORE twits prior to the NSFNET wind-down (hi Curtis). Many of the people who did actual engineering work at cisco were also not very agnostic when it came to cells, and had an effect on the company, which is one of the reasons I have always liked cisco compared to its competitors, who were not quite agnostic either but in the opposite direction. > There is another router vendor who has OC-12 router interfaces > about ready for production. Another (#3) is expected to release a > bang-up product real soon now. As Peter Löthberg pointed out, there are BFRs in production right now. Sprint is also not the only vendor who is using them to move traffic, although the majority of other users are currently using the BFRs as really fast star-shaped LANs, essentially. (I expect this to change very soon) > There is a choice in the market today for OC12 router interfaces. Not today there isn't. Maybe next month. There may be choice in what you can put at the end of an OC12 though, but it's either something smart or something you'd find at Hobson's Tavern. Sean.

2 1

Re: LSR and packet filters
by Sean M. Doran 14 Sep '97

14 Sep '97

rja(a)corp.home.net (Ran Atkinson) writes: > A reasonable security policy is focused on maintaining > network availability and uptime. How does a security policy of "turn off LSR handling" translate into anything other than an admission of completely missing the point that one should never ever ever ever trust any data based soley on where the network leads one to believe it has come from? Turning off a useful but under-implemented network service because it might be used to spoof the network origin of management instructions or routing information misses the point that the network origin is a really poor proof of validity of the messages or authority to issue them. Moreover, the under-implemented service itself may improve the security of communications between end systems. Quoting Radia Perlman: "The goal is to design a network that will guarantee that a packet transmitted between two nonfaulty end systems A and B will have a high probability of being delivered, provided that at least one path consists of nonfaulty components connects the two end systems. [...] The network layer makes no attempt to keep conversations private. If privacy is necessary, encryption must be done at a higher layer. Also, the network layer need not certify data that it delivers. For instance, it is possible for some malicious node C to generate data, get it delivered to B, and claim that the data was from A. It is up to the higher layer in B to differentiate between corrupted or counterfeit data and real data, using known cryptographic techniques". The proposal to turn off LSRR is a tremendously incomplete proposal to have the network certify the validity of the origin, at the cost of some additional utility and robustness from the point of view of end systems. However, maybe this isn't so surprising as I've seen you support another incredibly braindamaged security scheme that trades off scalability of the Internet in general for some degree of security between end systems. The problem isn't one of ES-to-ES security but one of endpoint to endpoint, where the ultimately the endpoints are the data generators and receivers (human or automation) who communicate through the end systems. The lesson of Kerberos and SSH and so forth is that ES-to-ES security is useless if one of the ESes itself is compromised. > If one focuses exclusively on diagnostic tools, one's > network will be down much more often than if one strikes > a reasonably balanced overall perspective on things. > All IMHO. But at least you will know WHY your network went down, and might be have enough information to get it back up again, and prevent the same thing from happening again. --:) In any event I don't think that disabling LSRR in any way makes networking equipment more robust, and that is what you appear to be arguing. > I will note that its none of someone else's business what > one's internal topology looks like. Sure it is. Or rather, it is useful to be able to infer a number of path characteristics between two communicating endpoints for such things as flow control and route selection. Networks and computers exist to offer services to users, and obscuring information that makes service use or selection difficult is a poor policy. I would agree with you if you modified your note to, "it is no business of anyone not authorized to use a network what that network looks like beyond how it presents itself externally", although this is incomplete because it doesn't preclude marketers telling whopping lies to potential authorized users. (caveat emptor? :) ) > The only _legitimate_ need of a peer is to be able to > isolate the problem to one's network (or someone else's > network) so that the peer can then come after one (or > one's NOC) to fix the problem(s). Again, networks exist to benefit users. The need of the aggregate of networks called the Internet is to make users happy, and usually involves more than "oh it's *their* problem". Tools to provide meaningful diagnoses of ES-to-ES connectivity that users can run on end systems is work-reducing for network operators, particularly as those network operators obviously would have access to the same tools. > So I'm not trying to kill off LSR as a diagnostic tool, merely > limit the downside operational risks of LSR to a reasonable > level. The ultimate goal of my proposal is to _enhance_ > network availability. How does LSR reduce network availability except in the case of implementations that slow-switch option-ridden IP datagrams and have no equivalent of SPD, or intermediate systems (gee, it's OSIspeek day, isn't it?) that don't use reasonable means to authenticate and keep private things like routing information exchanges or management sessions{ Sean.

2 1

Re: not rewriting next-hop, pointing default, ...
by Sean M. Doran 13 Sep '97

13 Sep '97

Avi Freedman <freedman(a)netaxs.com> writes: > The danger with this approach is, obviously, that the router that you > try to do this to can go away. In which case you shoot yourself in the > foot. Some day, someone will send me a valid use of 'set ip next-hop' > but I haven't seen a good one yet. I believe initially it was dropped into route-maps to deal with situations involving having three different ASes share a broadcast LAN in Washington D.C. as an internal link. (AS 1239, AS 1790, both sharing a single IGP instance, AS 1800 with a different IGP instance, to be specific. Running two independent iIS-IS instances on a single wire was fun too.) FSVO "valid use", but it did make things work. Sean.

1 0

Re: not rewriting next-hop, pointing default, ...
by Sean M. Doran 13 Sep '97

13 Sep '97

"Alex.Bligh" <amb(a)xara.net> writes: > Failing this, the ability to disable responding to packets (*) > with source route set on the Cisco *host* TCP/IP stack > (and continue to forward them), Mourn the death of TUBA telnet... :) What you might want is to make sure that management functions can only happen over a separate private IP network. This has been a long-time engineering goal of one network at some priority or other. Then, some protection for routing protocols to make them both more robust and more secure, and life is a bit nicer. (Although taking an axe to all the routing protocols in use today has a strong appeal, actually, but that'll come later...) Unfortunately, though, in the absence of a method to query routers about their forwarding (i.e., "what would you do with this traffic profile?"), route calculation and NLRI redistribution policies, any tool which can help infer that from anywhere in the Internet is of use. I hate traceroute, I think it's a dreadful hack, and it is really hard to use it correctly for all sorts of reasons, lots of them having to do with the observer problem. LSRR helps enormously, and has been of critical use in the past. Killing it off to provide some warm fuzzies to operators who are still going to be exposed to lots of serious attacks on their routers and hosts strikes me as nearly as unreasonable as simply turning off routers and encasing them in concrete to make them safe. What would be REALLY nice is if lots of new hardware and software that doesn't keel over dead or use a really slow path to forward packets decorated with the LSRR option were deployed in everyone's networks. Sean.

1 0

Re: switching versus routing ATM redux
by Vadim Antonov 13 Sep '97

13 Sep '97

>> Who is Richard Irving? > >Tim Bass with a new spelling? Thanks, Sean. I'm curious if anybody knows why abundance of ellipsis in text is such a good indicator of TBism? You can make a five-liner bogon rejector based on the phenomenon, and in most cases it'll work wonderfully. --vadim PS Now, don't argue that bogon filtering is irrelevant to NANOG. Get a life :)

1 0

Re: switching versus routing ATM redux
by Sean M. Doran 13 Sep '97

13 Sep '97

Richard Irving <rirving(a)onecall.net> writes: > Who is Richard Irving? Tim Bass with a new spelling? > It is sort of an obsession of mine Wow, good guess, Sean. Sean.

1 0

Re: switching versus routing ATM redux
by Richard Irving 13 Sep '97

13 Sep '97

On Sat, 13 Sep 1997, William Allen Simpson wrote: > Wading thru the flood in the past two days, I was wondering why Carmen > Hillenburg <carmenh(a)onecall.net> is answering Richard Irving > <rirving(a)onecall.net> email? My significant other used my email while I was at work ;> > > Thus, ATM takes more bandwidth (is slower) and more cell switches (is > slower), cumulatively at every hop. Slower is slower is slower.... > Interesting note, I think all cross country timing data coming in is across ATM paths. Anyone have HSSI ? Regarding the deluge. It started when someone said, "Ok, what advantage does ATM have that IP doesn't" and I named 2. It started a Holy war. I had no Idea... Chris, I may never respond to you again.... ;) However, it is dragging to an end. *phew* We will know a fairly close representation of the ratio of overhead to cross the country, vs the speed of light ;). We have had input from some of the more interesting people in the field. And many interesting , yet *differing* views, yours is yet another. I would have stopped it long ago, but I felt obliged to at least answer. It is sort of an obsession of mine to make the data I *see*, correlate with the information the experts in the industry are offering...... Who is Richard Irving? No one! Just a tech like you, tasked with "The Net". Our company is an IXC, we run a hybrid-exchange (Giga-POP), and also carry our own ATM and IP circuits. (Routers, ATM Switches, IP Switches, and Telco:(ISDN/Pots) Switches.) We have a couple thousand T's around the country , (not all ip ;( ), Lots of "Hot glass" (up to OC48), and clean circuits. (Bandwidth Heaven) We buy/sell pipe from MFS, TWarner, Ameritech, etc.. And provide advanced communications to customers: U.S. based ATM, IP, LD, LDIP, and Frame. We function primarily as a bandwidth/advanced communications *wholesaler*, so you don't hear of us much. We are a C based shop, and also provide "Custom" Data services to the Carrier/Communications industry. Want a brochure? : mailto://techsale@onecall.net, or mailto://techsale@indyx.net as I am beginning to sound too much like a salesman for comfort. ;) No one, Just a tech who has to deal with so many technologies throughout the course of a week, that I begin to "bleed over" acronyms, and confuse everyone when I post ;) But, I am a member of NANOG, I think that counts! ;) Richard

1 0

Re: ATM (was Re: too many routes
by Richard Irving 13 Sep '97

13 Sep '97

On Fri, 12 Sep 1997, Vadim Antonov wrote: > Actually, 4000 miles is a very reasonable estimate for a cross-country > path physical length. That's why i took it as such without much > arguments. I am thinking it may be, we are getting together timings, and people are reporting the runs. The calculations are getting lower as we go. It is starting to look 30 ish. I agree this is not as significant as I thought it was going to be.... However, it is interesting to close in on. ;) > > > This implies that 39% of the actual timing is overhead. > > Hey, did you ever measure delay on a real cross-country fiber? > Did you compare that with pings between attached routers? > (Hint: i used to work for a long distance carrier). I do. And have for a while. That doesn't mean anything one way or another. Why don't we knock off the I am , I was, and I will be's and lets get the answer from data coming in. ;) This thread has been joined by some rather interesting people. All of which humble me, to be sure. (not that it is a difficult thing ;) The interesting thing is, most of these people are interested enough, that the data is coming in... I suspect, we may be able to get to a "reasonably" accurate ratio, but it should be interesting. Aren't you curious ? Or, do you have current data ? If so , post it. > > 74 ms you quoted is actally a nice RTT, for a loaded network > particularly. The first SprintLink's DS-3 between DC and > Stockton, CA had 80 ms (that's clearline, w/o any routers in the We have one down into the mid 60's now. Check the archive. > Now, would you care to explain how 0.3ms delay per router can > make things worse, considering that the average number of > _backbone_ hops for inter-provider trace is about 6? > At each juncture , layer 3, exists an opportunity for routing interaction. This is "for better" or "for worse". The better, is not what I am concerned with.... If indeed a router, participating in full tables, only introduces .3 ms delay, on a median, then the market bodes well.. But, I am concerned with the "distribution of the curve" so to speak. How -wide- is it.... How do we narrow it ? > --vadim >

1 0

The subject of being off the subject in the nanog list
by Bill Clark 13 Sep '97

13 Sep '97

With the thread that has been going around about being flamed for posting inappropriate subject matter on this list I believe I have an easy rule-of-thumb. Not saying by any means that I would try and impose my own beliefs on anyone or that mine are superior. Merely a suggestion to keep in mind. This list is not the following: Where I can I find this? Who can tell me what where this company peers? Why doesn't my router work? Anyone know if there is a patch for such and such IOS? Can you tell me how to add a route to my commodore 64? Politics What is the meaning of life? Now with that said, if someone were to ask hey anyone know where I can find gated? Then fine that's acceptable but 40 different people shouldn't post to address hey get it here at ftp.gated.com Why not send e-mail directly to that person. If somebody else says hey I am looking for that too, don't post it to nanog, send e-mail to the person who posed the question, hey if you get a good answer forward to me. By applying this practice we can eliminate the unnecessary e-mail and make life a little easier for yourself. It might be easier for you to post to the group and wait for some other people to post to the group but you are inconveniencing the rest of us, you want the benefits you bear the inconvenience of looking up that person's e-mail address and replying to them. Concept discussions are generally well received here, but hey my router keeps rebooting doesn't really need a thread of weeks to follow. Okay, I'll get off my soapbox now and prepare to get flamed myself. Bill Clark New Century Computer Solutions Network Engineer bclark(a)nccsinc.com

2 1

switching versus routing ATM redux
by William Allen Simpson 13 Sep '97

13 Sep '97

Wading thru the flood in the past two days, I was wondering why Carmen Hillenburg <carmenh(a)onecall.net> is answering Richard Irving <rirving(a)onecall.net> email? And why, with all the terminology being flung around, they don't realize that the term "Broadband ISDN" came years before "ATM"? The former is Engineering Speak, the latter Marketing Speak. FYI, they are confused. BRI ISDN is "baseband", not "narrowband". 10-base-2, 100-base-T, and gigabit ethernet are also "baseband". Cable TV channels (6 Mbps) are "broadband". Old 2400 bps satellite links are also "broadband". And why cannot either of them tell the difference between measured RTT of a ping and measured RTT using a real IP hop measurement tool, such as is available from LBL? And why there is any argument about forwarding latency, since by definition the last bit of the last ATM cell is not going to arrive any sooner than the last bit of a packet containing any IP datagram? Measuring the first bit arrival of cut-thru-switching is a waste of time. Processing of the IP datagram at the destination will not occur any sooner than the last bit.... And we all know that the task switch in the source and destination dominates the end-to-end timing (especially of non-fast-path ICMP messages like ping). A good ATM switch will buffer the entire packet anyway, to avoid wasting downstream bandwidth when one of the cells is dropped. No different than a router. By definition, there is much more link overhead (at least 2 ATM headers) and forwarding overhead (at least 2 ATM cell switches per SDH hop) for an IP/ATM/SDH datagram than an IP/PPP/SDH datagram (1 small header and 1 packet switch per SDH hop). Thus, ATM takes more bandwidth (is slower) and more cell switches (is slower), cumulatively at every hop. Slower is slower is slower.... And, on another thread, I was pretty sure that NetStar cum Ascend had a 622 Mbps OC-12c (STM-4) IP/PPP/SDH card long before Cisco. They were engineering it nearly 2 years ago. Did they not sell any? At the time, both Cisco and NetStar had very talented engineers on the OC-3 and OC-12 projects (and I'm not easily impressed), but the Cisco folks were hampered by the speed of their backplane and buffering on their card. NetStar had the backplane bandwidth and plenty of buffering, but had routing software instability. Reports on this list were that they were fixed. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0