- Test - lists.nanog.org

Re: Chiappa blows his brains out (was Re: Policy Statement)
by jnc＠ginger.lcs.mit.edu 30 Jan '96

30 Jan '96

<There's an interesting point in the middle of this, about how multihoming presents technically rooted problems no matter *how* we do the addressing, even if we solve the conflict he mentions, and that these problems have an impact on what policies it is useful to discuss...> From: "Joel M Snyder, writing fool" <Joel_M_Snyder(a)opus1.com> GIVEN that I have sufficient knowledge about routing as is necessary to fully understand every technical issue involved Sorry, I guess I just assumed the wrong interpretation of what your question was about. (Also, to be honest, if we've got to the point that most everyone understands these issues, I guess it's time for the champagne... :-) GIVEN that I have a rudimentary and imperfect understanding of the political and economic issues regarding IP numbering and the propagation of routes thereunto I'm not sure anyone has a truly "global" view of this, although if one listens on this and other lists hard, one can start to get a view which integrates the large and small ISP's, equipment suppliers, etc, etc... GIVEN that there exists some set of organizations who want to purchase multiple T1s from multiple independent suppliers ... HOW do I resolve the conflict between justifiable corporate service requirements and the expressed statements ... that anyone who does not consume at least a /18 worth of address space is not worthy of being globally routed? To start with, this is another case where setting the size-based filter for routing updates is having deleritous effects. Again, all we're doing is creating a demand for address space, and as long as there is no well-modulated back-pressure on address space (such as charging for it), I'm not sure I see any easy way of dealing with it. Second, whether it's a /18 or a /24 is of no interest to the routing. Let's assuming we can separate the addressing issues out, to focus just on the routing cost, which is going to be the same *regardless* of how you resolve the address space issues. This is important: *** No matter how you do the addresses, you *still* have the problem that if *** a significant percentage of customers want to be multihomed, and we still *** don't have any mechanism or tools for reducing the scopes of those *** advertisements from global (such as I mentioned in my original message on *** this thread), we will find it technically impossible to provide this *** multihoming capability to a large number of users: we will be rerunning the *** very routing table growth (tracking local sites individually) that caused *** us to go to CIDR in the first place. I don't know about you, but I could do without a re-run of that particular learning experience! :-) Ideally, in solving this, I would take a monetary approach, which is to say "what are the true costs of this multihoming, and given that, is it important enough to the client for them to pay for it", but of course we don't have a charging mechanism for routes that would help to answer this, and maybe never will. So, I can't use that copout. Maybe a better question is to ask "what goal are they really after with multi-homing", because if the answer is "reliability", then perhaps they get more bang for their <insert-local-currency> with things like multiple access lines, etc. I am asking, I suspect, not for a technical answer (there being none other than Chiappa's "it's gonna cost"), but the most politically correct answer to give the organization I understand that you have a very "bottom-line" concern, which is "what do we tell the customer", but I hope that this time I have made clear to everyone that there is no solution to the technical question of "can we provide multihoming on a large scale", *at least in the system as it stands today*. (I.e. if this is an important goal we need to get cracking on technical solutions...) Any policy discussion must take place in an environment which is aware of this technical constraint. Thus, your question about the policy conflict you pointed out is interesting and true, but ultimately not a critical one... Noel

1 0

Re: Static IP addresses for Dial-up
by Paul Ferguson 30 Jan '96

30 Jan '96

At 02:19 AM 1/30/96 +1100, Robert Elz wrote: > >You're expecting me to obtain one of those things for my system >at home? And assuming that password type capable access >protection is the only kind of protection I care about. > Well, not exactly. I was thinking along the lines of something a little larger than 'home' access. :-) >Lets be a little reasonable please - access filters aren't >dead yet (I would like to see them vanish, and I would hope that >one day that might happen, today isn't that day). > >I will believe this has happened when cisco no longer support >packet filtering in their routers. > >kre > > My point was that filtering on source addresses is not exactly the most secure method of access control. - paul

2 1

Re: Chiappa blows his brains out (was Re: Policy Statement)
by jnc＠ginger.lcs.mit.edu 30 Jan '96

30 Jan '96

From: Scott Huddle <huddle(a)mci.net> Probably the best thing that be currently supported is getting two diverse connections to a single provider that can globally aggregate your network. The connections should go to different POPs and should follow seperate physical paths. This should provide you the desired reliability and load sharing. This solution has been pointed out before. Also, Dorian Kim sent in a good message to the Big-Internet list talking about reliability (the stated goal of most multi-homing), and the 7 places you could do redundancy, and what was really important in achieving reliability, which contained a lot of good insight. Here's his message (appended). Noel -------- Date: Fri, 1 Sep 1995 03:57:16 -0400 (EDT) From: Dorian Rysling Kim <dorian(a)cic.net> To: ... big-internet(a)munnari.oz.au Subject: Re: Multihoming .... There are many places where redundancy can be achieved with multiple connections. 0) Equipment spares on site 1) Diverse local access of the two links 2) Diverse routing of the physical links into COs 3) Diverse routing to different local providers 4) Diverse routing to different regional providers 5) Diverse routing to different large transit providers (MCI, Sprint, ANS, Alternet, Eunet etc) 6) #5 + connection to the NAPs. All of the above give you redundancy at various single points of failures. In my experince, #0 - #2 should be considered as important in providing true redundancy as 4-6. In fact, in most cases, the most common case of outtages come from equipment failures, and circuits themselves, and sites who are looking for multihoming for the reason of redundancy should look at the cost of having 0-2, and think long and hard about whether multihoming is what they really need. -dorian

1 0

Re: Static IP addresses for Dial-up
by Robert A. Rosenberg 30 Jan '96

30 Jan '96

At 13:46 1/28/96, Peter Dawe wrote: >Demon Internet Services provide an IP address for every dial-up >customer. Most other ISPs have taken the view that this is a waste of >valuable IP space and allocate IP addresses dynamically. > >How should our industry respond to ISPs who behave selfishly and do >not take into account the good of the network? Demon (as it appears to the Internet [due to their dynamic modem binding/routing code]) is all permanently wired (but randomly powered-up/connected) hosts. The fact that the connections are via dial-up not leased lines is not relevant to how they appear to the Net. If every one of their users had their own leased line OR dial up port phone number would you say that they wasting space? There is no significant difference between these latter connection methods and Demon's actual "Dial any of our POPs to make your connection" method. All they are doing is sharing the modem ports instead of assigning a separate one to each customer. As they have noted, dynamic addressed does not fit the model of what they are selling (ie: CONNECTION not ACCESS). What types of Daemons/Agents are being run by the user while they are connected is not important due to the STATIC IPN (Something that would NOT be possible with a dynamic/random IPN number). Until Dynamic DNS is out in the field, Dynamic IPN supports ONLY Access not Connection (and as I noted, Demon sells Connection not just Access).

1 0

Re: Policy Statement on Address Space Allocations
by Vadim Antonov 30 Jan '96

30 Jan '96

Michael provided one reason why multihoming isn't always worth it. The other reason is that pretty many problems in Internet are caused by routing instabilities, and multihoming only provides more ways for the instabilities to affect the "redundant" network. Most of global routing problems can be classified as "Bysantine" in theory of fault-tolerant systems. I.e. faults which cannot be handled by replication of components. In my experience, purchasing a UPS is a much smarter way to spend money on improving reliability. Note that regular telephone service does not generally employ multihoming and dynamic adaptive routing, but has a lot better reliability. Something to think about. --vadim

2 1

Re: Policy Statement on Address Space Allocations
by Vadim Antonov 30 Jan '96

30 Jan '96

Well, i meant precisely the city loops which aren't multihomed, and that's what customers are using to access telco facilities. I.e. POTS customers (and their PBXes) aren't multihomed in the sense used in the discussion. The better term for telcos are doing for reliability between switch sites is called "standby", which is *not* the same as multihoming with adaptive routing. The point was that high reliability may be achieved w/o tricky things like adaptive routing, --vadim >From sdenny(a)red.hex.net Mon Jan 29 21:14:22 1996 Received: from tiny.sprintlink.net (tiny.sprintlink.net [199.0.55.90]) by titan.sprintlink.net (8.6.9/8.6.9) with ESMTP id VAA09936 for <avg(a)titan.sprintlink.net>; Mon, 29 Jan 1996 21:14:21 -0500 Received: from red.hex.net (sdenny(a)red.hex.net [198.175.15.226]) by tiny.sprintlink.net (8.6.9/8.6.9) with ESMTP id VAA14645 for <avg(a)sprint.net>; Mon, 29 Jan 1996 21:14:11 -0500 Received: (from sdenny@localhost) by red.hex.net (8.6.10/8.6.10) id UAA02836; Mon, 29 Jan 1996 20:14:00 -0600 Message-Id: <199601300214.UAA02836(a)red.hex.net> From: sdenny(a)red.hex.net (Stephen Denny) Date: Mon, 29 Jan 1996 20:14:00 -0600 In-Reply-To: Vadim Antonov <avg(a)sprint.net> "Re: Policy Statement on Address Space Allocations" (Jan 29, 4:19pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Vadim Antonov <avg(a)sprint.net> Subject: Re: Policy Statement on Address Space Allocations Cc: nanog(a)merit.edu, sdenny(a)red.hex.net Status: R On Jan 29, 4:19pm, Vadim Antonov wrote: > Note that regular telephone service does not generally employ multihoming > and dynamic adaptive routing, but has a lot better reliability. Something > to think about. }-- End of excerpt from Vadim Antonov Regular telephone service is indeed generally multihomed except for the final loop from the central office. SS7 is a major pain partly because of the multiple routes it supports. - Multiple links in linksets (partly for capacity, partly for reliability) - Multiple linksets in routesets, where each linkset terminates on a different node Typically the CO is "multihomed" to two mated STPs for signaling traffic, and user traffic is routed through multiple tandems based on load, availability, cost and destination. Of course SCPs are also deployed in pairs. All this is in addition to the redundancy built into each piece of equipment, or the underlying transport (e.g. sonet). Of course none of this stuff comes for the price of a Cisco router either. What *is* true is that the telephone network is more or less a static network in terms of routing (although becoming less so). It would be big news indeed if a new CO just popped onto the network and started "announcing" itself! This "static routing" idea makes for ultimate control and predictability even with multiple routes. Stephen -- --------------------------------------------------- Stephen Denny sdenny(a)hex.net Member of the Technical Staff, Hex.Net Superhighway

1 0

Re: Policy Statement on Address Space Allocations
by sdenny＠red.hex.net 30 Jan '96

30 Jan '96

On Jan 29, 4:19pm, Vadim Antonov wrote: > Note that regular telephone service does not generally employ multihoming > and dynamic adaptive routing, but has a lot better reliability. Something > to think about. }-- End of excerpt from Vadim Antonov Regular telephone service is indeed generally multihomed except for the final loop from the central office. SS7 is a major pain partly because of the multiple routes it supports. - Multiple links in linksets (partly for capacity, partly for reliability) - Multiple linksets in routesets, where each linkset terminates on a different node Typically the CO is "multihomed" to two mated STPs for signaling traffic, and user traffic is routed through multiple tandems based on load, availability, cost and destination. Of course SCPs are also deployed in pairs. All this is in addition to the redundancy built into each piece of equipment, or the underlying transport (e.g. sonet). Of course none of this stuff comes for the price of a Cisco router either. What *is* true is that the telephone network is more or less a static network in terms of routing (although becoming less so). It would be big news indeed if a new CO just popped onto the network and started "announcing" itself! This "static routing" idea makes for ultimate control and predictability even with multiple routes. Stephen -- --------------------------------------------------- Stephen Denny sdenny(a)hex.net Member of the Technical Staff, Hex.Net Superhighway

1 0

Re: Chiappa blows his brains out (was Re: Policy Statement)
by Scott Huddle 30 Jan '96

30 Jan '96

Joel_M_Snyder(a)Opus1.COM writes > GIVEN that there exists some set of organizations who want to purchase > multiple T1s from multiple independent suppliers for purposes of > reliability and load sharing yet have need for less than 255 unique IP > addresses, and GIVEN that certain extremely popular software products (such > as Netscape Navigator) which are important to these organizations were > developed by programmers who seem to have no knowledge of either efficiency > or the way that the Internet works, and GIVEN that I have sufficient > knowledge about routing as is necessary to fully understand every technical > issue involved, and GIVEN that I have a rudimentary and imperfect > understanding of the political and economic issues regarding IP numbering > and the propagation of routes thereunto, HOW do I resolve the conflict > between justifiable corporate service requirements and the expressed > statements on these mailing lists the past few weeks which seem to imply > that anyone who does not consume at least a /18 worth of address space is > not worthy of being globally routed? > > I am asking, I suspect, not for a technical answer (there being none other > than Chiappa's "it's gonna cost"), but the most politically correct answer > to give the organization (which is not Netscape). You present a hard edge case that isn't particularly well met by the current infrastructure and it can't necessarily be done well or even done at all. (Sean's tricky chocolate-consulting hack excluded). Probably the best thing that be currently supported is getting two diverse connections to a single provider that can globally aggregate your network. The connections should go to different POPs and should follow seperate physical paths. This should provide you the desired reliability and load sharing. -scott

2 1

RE: Chiappa blows his brains out (was Re: Policy Statement)
by lodge＠houston.omnes.net 30 Jan '96

30 Jan '96

Scott, >You present a hard edge case that isn't particularly well met by the current >infrastructure and it can't necessarily be done well or even done at all. >(Sean's tricky chocolate-consulting hack excluded). Probably the best >thing that be currently supported is getting two diverse connections to >a single provider that can globally aggregate your network. The connections >should go to different POPs and should follow seperate physical paths. >This should provide you the desired reliability and load sharing. Thank you, thank you, thank you. This is exactly the kind of pragmatic advice I was looking for. Saying "don't do it" or "multihoming costs" is not helpful -- this sort of answer is. Regards, Mathew

1 0

REMINDER NANOG Meeting
by Pam Ciesla 29 Jan '96

29 Jan '96

If you are planning on attending the NANOG Meeting February 15 & 16 in San Diego please register ASAP. You can do this either by e-mail or using the registration form on the Merit Web Page. Thanks Pam Ciesla

1 0