May 2000 - Test - lists.nanog.org

Re: Optical Crossconnects and IP
by Michael Shields 14 May '00

14 May '00

In article <200005141743.e4EHheW09551(a)sss1.gwi.net>, Fletcher E Kittredge <fkittred(a)sss1.gwi.net> wrote: > http://smg.ulb.ac.be/Preprints/Fortz99_29.html > > mentions it was in Infocon 2000... > > And oh, yes, most definitely worth the read. A very interesting paper, but it does have a key assumption that may limit its applicability: "The above definition of the general routing problem is equivalent to the one used e.g. in Awduche et al. Its most controversial feature is the assumption that we have an estimate of a demand matrix." The approach laid out by Fortz and Thorup is very pleasant in its ability to show that a simple weight-based model can come close to optimal traffic engineering. But without any way to quantify how accurate our estimate of the demand matrix is, we cannot know whether the projected weights are actually even close to optimal. And considering the elasticity of demand, I would argue that an accurate demand matrix cannot be constructed for most Internet backbones given currently available tools and understanding. I would be happy to be wrong about this. -- Shields.

2 1

screen default for character wrap
by Henry R. Linneweh 14 May '00

14 May '00

Is generally 72 characters, comes that way from Netscape on download and install, most word processors are that way too. I really doesn't matter what e-mail application you have, most are set up to handle that. -- Thank you; |--------------------------------------------| | Thinking is a learned process so is UNIX | |--------------------------------------------| Henry R. Linneweh

1 0

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