- Test - lists.nanog.org

RE: Please Format Your Posts
by Roeland Meyer (E-mail) 14 May '00

14 May '00

Okay, I think that I figured it out. This line should auto-wrap at 70 chars. I couldn't find the button because it is hidden when using mime types, encoded printable. It is now found and checked-boxed. Please reply and let me know if this wraps properly. My MUA automatically wraps it for me so I cannot tell the difference from this end. In response fo many helpful clues, I suggested Netscape becasue it also runs under Unix. In my case, I and using MS-Outlook2K, part of MS-Office2K, under Win2K, on a DELL latitude CS. Yes, that's a laptop. I left EudoraPro for this setup because of corporate org benefits, the mail hub is HP OpenMail, rather than exchange. I refuse to use MS servers, they crash too much (Caldera eServer is much better). The non-MS solutions simply require too much general magic and have large a tinker-factor to get them to work right. I use Netscape on my Caldera Linux/KDE workstation. For those who may need this information in the future: In Outlook2K/Tools/Option/Internet E-mail tab check MIME radio button set "Encode text using: None set wrap value(opt.). Agreed, not exactly intuitive and MS moves it elsewhere every new version, like it's an easter egg.

1 0

Re: Optical Crossconnects and IP
by Danny McPherson 14 May '00

14 May '00

> I don't care about transient loop induction while in the process of > converging. That problem is much harder to solve. What I do care about is > a table like the following handed to the NOC/operational folks. If it were actually implemented it wouldn't be something you'd hand to the NOC .. unless I'm missing something. You don't hand them your SPF algorithm, or your BGP decision algorithm .. it's all "magic". You'd much more likely be handing them something stating "We've enabled this feature, here's the knob that did it, here's how it works...". My concern with these packet-based pre-calculated restoration mechanisms is that they near deterministically introduce transient forwarding loops, loops that result in the same amounts of non-forwarding (network unavailability) time that normal path recalculation/IGP convergence would result in. The benefit of a circuit-based restoration mechanism (i.e. MPLS fast reroute with a pre-defined backup LSP) is that when you switch to a backup connection you know (with some level of confidence) that packets forwarded on the connection will not be tossed around like hot potatos until the entire IGP converges, SPF calculation throttles are reset, etc.., introducing instability in the network. -danny

2 1

Re: CIDR Report
by Danny McPherson 14 May '00

14 May '00

> 1) Routing Table size > Is this as important of an issue as it was 3 years ago? Nope, not > with M40s and GSRs as standard backbone routes. 100K routes is no sweat > with these boxes. Of course, some of the big carriers would have to > finally replace some of those older 7505s floating around their networks. Route and forwarding table memory and processors speeds are pretty much the same between GSRs, M40s, and 7500s. The packet processing capabilities are where the relevant differences are. As for if it still matters, well, the fact that it takes > 4-5 minutes for some routers to pickup a full BGP table from a single peer, or generate the updates to send to a new peer, well, not worrying about this sure isn't going to increase network availability any. > 2) IP Address Space Scarcity > There is no real address space scarcity. We still have most of > 64/2 to go through. And there is always an easy answer to this "problem" - > turn IP space into a commodity and have an exchange system where folks > purchased address space from each other. This would result in the hoarded > "class A" space being thrown back into circulation, as the companies that > had them would have an incentive to unload them - money. As IP space is > really not that scarce (and would be less so with the Class A's in > circulation), the prices would be reasonable. When they became > unreasonable, there would be a market-driven move to IPv6. Ah, capitalism. > > The answer to most of these issues is to allow much smaller allocations in > a specific block - say 65/8. Allow /24-/21 allocations in this block for > smaller multihomed enterprises. Then, start cracking down on the other > blocks by filtering smaller prefixes. This would enforce necessary > aggregation where possible, but still allow multihomed enterprises to > obtain an appropriate amount of IP space on their own. I'd venture to say that if routers were capable of maintaining 100K+ prefix filters, and secure, reliable registries were available to populate the filters, and these longer prefixes (/21-/24, or maybe even longer) were allocated and registered in a reasonable manner, and tools were in place to efficiently manage all of this, and again, the routers were capable of handling all of this, well, I doubt Randy or others would have as big a problem accepting appropriately identified longer prefixes from peers. Of course, until the fairy dust is sprinkled over all our networks and these things are no longer a problem, we'll just have to deal with them, in the way that the individuals, and their employers see fit. -danny

2 1

Re: Optical Crossconnects and IP
by Danny McPherson 14 May '00

14 May '00

> I found this sentence to be quite instructive. > > \begin{quote} > In connection with link failures, we note that one could > pre-compute a good weight setting for each possible link > failure and have them ready for loading when needed. > \end{quote} > > That has some interesting operational issues, one would think, especially > in large networks that are dense partial meshes, with associated link > failure scenarios. Indeed. Especially considering the potential introduction of transient fowarding loops when attempting to utilize pre-computed backup "links" in a vanilla DA-based packet-switched network. -danny

2 1

Re: Optical Crossconnects and IP
by Vadim Antonov 14 May '00

14 May '00

Tony Li wrote: > A key observation here is that the point of an optical cross connect is to > provide a real circuit, not a virtual one. Tony - the way i see it, a "real" circuit is something which requires a technican to go on site to connect or disconnect it. Any circuit which can be routed under software control is a virtual circuit. In this case these wavelengths or whatever are no different from CBR flame delay or ATM circuits. Now, if one wants to get really philosophical, it all depends on time frame. A capacity planning software may issue orders to technicans to go and do things -- but it'll take days. If you're ok with that kind of response time, the "real" circuits are also virtual ;) The funny thing is, the change rates in traffic engineering world are pretty close to the human-assisted VC switching's :) --vadim

6 8

Re: Multi-home II
by Rural CNE 14 May '00

14 May '00

> Can you please help point out a good may to multi-home? > I would like to get a site put in a Co-lo in the west coast > and one in the east coast. Both would be different co-lo's. > Could I get a single ASN and handle both places with different > subnets under the same ASN? To be honest, I don't know. If you're asking how would I approach this problem here's where I would start... http://www.merit.edu/ipma/docs/isp.html http://infopage.cw.net/ After that, I would start hunting down somebody who has done a solution similar to the one above and try to contract them for the design and implementation. Putting out a formal RFP wouldn't hurt either. -brad (Rural CNE) bwalters(a)inet-direct.com

3 2

RE: CIDR Report
by owen＠dixon.delong.sj.ca.us 14 May '00

14 May '00

> I actually agree with you here as well. relying on infinite router table growth is not a scalable strategy. We need something else. > > > Just a small technicality here, noone is talking about infinite routing table growth. There are only 4 billion (roughly) possible prefixes if you route every node as a /32. While 4 billion is a large number, it is far from infinity. If you believe the IPv4 will continue for many years to come, then the set of possible routes is very finite. Of course, the number for IPv6 is much larger in theory, but when you consider that the last 6 octets are reserved for the MAC address (essentially), that leaves 80 bits, which is 1,208,925,819,614,629,174,706,176. Again, a large number, but, far from infinity. When you further consider that on the backbone, only the first eight octets are at all likely to be significant for routing, you come to 18,446,744,073,709,551,616 prefixes, which is still a large number, but even further from infinity. In my opinion, eventually, we will need to find a way that each organizational unit is issued a portable, non-renumberable prefix which stays with that organizational unit. Some larger organizational units may need additional prefixes, depending on the size of the suffix. Generally, it follows that most strategies for aggregating such prefixes will tend towards entropy as organizational units change their topological relationships with other organizational units. Thus, the only way to preserve aggregation is to make the prefixes issued to organizational units a function of their topology, and force renumbering. While this is a simple matter for topologies which involve only two organizational units as neighbors, it becomes n! (n factorial) complex for organizational units which have n neighbors. Even with IPv6, I do not believe such a prefix numbering scheme is practical. Owen

2 1

Multi-home II
by Rural CNE 14 May '00

14 May '00

> (There are very few valid reasons to multi-home, please consult > with RFC x, BCP y, and an experienced network engineer.) > Roger that. Some of the reasons I have seen discussed have included: 1.) Reliability / Availability 2.) Geographically distributed client locations I would like to add: 3.) Performance / Throughput The old "we'll just add another subinterface to the hssi port, they can't tell the difference anyway" school of network design just ain't gonna cut it anymore. The Internet has now become the e-Internet. Upstream providers are not created equal. IAP's and other end-systems will be migrating to, or multi-homing with, those service providers that can handle the additional traffic load generated by xDSL, cable, or other high bandwidth technology. (...And your point is?) I would argue that lower tier multi-homing has contributed to the growth of the CIDR tables. Examining and resolving the issues surrounding the cause, multi-homing, would be more beneficial than promoting an upstream provider policy dealing with the effect, CIDR growth. -brad (Rural CNE) bwalters(a)inet-direct.com

1 0

SAIC strikes again
by Sean Donelan 14 May '00

14 May '00

As NSI moves all the GTLD servers to a common platform with common software and common management, I thought I would include a quote from another SAIC project which also uses identical systems as back up. > Two servers running 17 hours a day manage the database. "If one > breaks down the other will back it up," according to SAIC Program > Manager Craig Sinclair. "The system is highly reliable." The FBI national gun buyers background check system has been out of service since Thursday.

1 0

Re: CIDR Report
by Danny McPherson 13 May '00

13 May '00

Perhaps part of the problem is this preconceived assumption that one requires portable address space and at least one unique AS number to be able to connect to the Internet in any reasonable manner, even if they're single-homed, or multi-homed to a single provider, etc.. Given, there are plenty of instances where it's indeed the optimal approach, but it's far from being the norm, even though it often seems to be evangelized as such. The other issue that folks seem to be overlooking is that while routers are indeed more capable today (in terms of route and forwarding table space and processor speeds, hardware-based forwarding and the like), there are still a number of things that could be significantly improved upon . Things that would make the Internet far more reliable as a whole, but won't be attainable if we forget about things like aggregation, reasonable justifcation for IP addresses, and address portability. For example, the fact that most large neworks (you define) don't perform any type of route prefix filtering between one another, but only at the customer ingress (if there), leaves a huge opportunity for (un)intentional unauthorized advertisement of another's routes. Think about it, right now nearly half of the root name servers could be pretty much completely taken offline by simply injecting a more-specfic advertisement for the network in which they reside into BGP. The other half, well, you could easily redirect ~half their traffic to an "alternative" location .. unless, of course, they reside within an address block which mean-old-Randy, or other networks are concerned about, then the number decreases slightly, but is still very substantial. Now, as for the actual impact this deaggregation and portability has, well: o if today I can't maintain a few 100K policy entries defining valid paths at the edges of my network o or today I have no _reliable means of determining if the source of the information is valid o or today I can't reach to the databases during policy definition time o or especially, today, can't store the polices on my BGP routers or reasonable apply them to the associated peers Well, I'd say 5 or 10 (conservative) potential additions for each new prefix should indeed be a concern. And this is just from a control plane perspective. Think about if you actually wanted to utilize those same policies to perform some type of ingress SA-based packet filtering on a per-peer basis (it could easily decrease the impact of spoofing attacks by an order of magnitude). Because of asymmetry, the packet filter can't be based on the forwarding table, it has to be based on the potential number of valid paths to the destination, and has to be performed in hardware. Now, think about the impact that 5 or 10 (conservative) potential additions for each new prefix would have on the forwarding plane. The CIDR stuff, the prefix-length filtering driven by Sean, Randy, myself and others over the years, the address portability and allocation stuff, it all feeds directly into this, and absolutely has a substantial impact. To toss it all, while forgetting about reliability and availablity, well, seems short-sighted to me. -danny

3 2