- NANOG - lists.nanog.org

Re: NANOG Meeting
by Sean Doran 20 Aug '95

20 Aug '95

>I think this is supposed to say Pittsburgh, PA. Ah, no, this is just the ultimate in address portability. Sean.

3 2

Comments on draft-ietf-cidrd-ownership-01.txt
by Dave Crocker 19 Aug '95

19 Aug '95

This note offers comments on the technical and operational aspects of the proposal for large-scale use of "address leasing" as proposed in: "On the Implications of Address Ownership for Internet Routing", I-D draft-ietf-cidrd-ownership-01.txt, by Rekhter & Li. The draft has been produced within the cidrd working group and is intended for publication as a Best Current Practises official IETF document. I'm copying the message to several lists due to: o the likely short general review that will be possible once the draft leaves the working group, o the types of concerns I raise in this note, o the likelihood of widespread impact from the proposal, and o the simultaneous discussion of related issues on those mailing lists, but I request that any discussion of my comments take place solely on the cidrd mailing list. Comments follow the document's section headings: 1 Abstract Paragraph 2 offers the document as a treatise or review of issues, citing a "focus" on one approach. The primary principle that the paper observes is that flat address spaces don't scale well. In fact the paper is simply a direct proposal for a particular scheme and should be characterized as such. It makes no effort to consider alternatives other than flat addressing nor even to consider the full impact of its recommended scheme. The title of the paper is not helpful and may well be misleading. It introduces the concept of address "leasing", rather than only discussing some drawbacks to permanent "ownership". Hence I suggest that the title of the paper be changed to something like "Proposal for General Use of Address Prefix Leasing". 2 Address allocation Paragraph 3 appears to claim that address ownership has not actually been the policy for more than 15 years and therefore implies that the idea of address leasing is not new and frankly experimental. This is at best incorrect and at worst misleading. For more than 15 years user sites have been given permanent network numbers and have been free to attach via any available provider using those numbers. It is only quite recently that providers have begun to require use of CIDR space and/or change addresses when changing providers. The paper should not attempt to suggest to the reader that leasing is anything other than a fundamental change in Internet address administration policy. As such, the paper should acknowledge and emphasize the frankly experimental nature of leasing done on a global scale. (Yes, I did say experimental. Contrary to the comments on the cidrd mailing list there has been no large scale use of a leasing policy and no real analysis of its effect. When claims are made to the contrary, they seem to hinge on a) the lack of changes needed for the large transit providers and their routers and b) a long history of organizations occasionally changing their IP network numbers, albeit mostly painfully. A side effect of this is that some other schemes which have been handily dismissed as experimental probably warrant more substantive consideration. One more presumption that warrants attention is that the Internet does not have time to consider alternatives. The facile counter to this concern is to ask whether the Internet has time to see CIDR and address leasing fail, eliminate local providers, or otherwise kill the Internet?) 3 Addressing and routing (no comments) 4 Address ownership Paragraph 4 refers to "space complexity" -- which I seems to mean the amount of space required -- for "the different schemes". Which schemes? The paper only discusses totally flat and totally hierarchical schemes. Is this total of 2 schemes what is being cited? In the next paragraph the paper states the importance of having an address reflect the topology of the network. Since the Internet is not a tree, but instead is a messy mesh one must ask by what procrustean process the Internet topology is to be represented by (relatively) stable hierarchical addresses? It is certainly true that a graph can be represented as a tree by taking a particular view of it but that representation only holds from that view. Such a view is applicable to snapshots needed when making routing decisions but not for globally-absolute addressing. The paper also says that changing an address is required as the network topology changes. This simply isn't true or, at least, is not what is being done or proposed. Internet topology changes all the time and sites are not required to change their addresses. At best this paragraph is seriously imprecise. At worst it is seriously wrong. The end effect is to aid in the myth of Internet topological hierarchy. We need to reverse this misleading view. The seventh paragraph discusses routing table exceptions. (The second sentence is awkward and should be re-written.) Exceptions are those entries which do not conform to the hierarchical model. The paragraph acknowledges that the Internet isn't strictly hierarchical but it then entirely misses the implication. For example it fails to note the effect of large-scale occurrence of multi-homing by local providers and users. (During discussions, the CIDR document has been referenced for its consideration of multi-homing. In fact that consideration clearly presumes that there IS a legitimate hierarchy in the Internet, which presumption no longer applies.) The last paragraph in the section makes quick mention of a possible impact on organizations which "sub-lease" numbers. This means that a local provider which changes transit providers will be forced to force its customers to renumber! While large transit providers well might not view this impact as substantial I suggest that it is, in fact, quite serious and deserves rather more discussion. For example CIDR and address leasing is likely to create a basic barrier to entry for local providers. ("Barrier to entry" is offered as a euphemism for "put all of them out of business.") They might not approve of such an effect. 5 Recommendations The first paragraph contains the disclaimer "Existing address assignments and allocations are outside the scope of this document." However the handling of existing addresses has very much been a part of working group discussions and appears to be very much a part of the intent behind pursuit of the address leasing model. In particular, working group discussions have cited CIDR as no longer being adequate when applied for new addresses only and that "recovering" existing addresses is required. Please note that I said "required". That, at least, is the message that has been communicated in recent working group discussions. If that message is wrong then we need to hear rather clearer explanations for the near-term need to promulgate a leasing policy. The proposal needs to attend to this issue directly and should not pretend that it is anything other than an immediate and pressing concern. The next-to-last paragraph acknowledges that users might incur some cost when renumbering, but the paragraph elides further discussion of the issue, instead simply saying that organizations need to consider tradeoffs. I suggest that a paper which is proposing a major change for the Internet is obligated to offer rather more detail about its impact and rather more concrete information for considering tradeoffs. It needs to list and discuss those tradeoffs. At the least that will demonstrate detailed understanding of the proposed policy's impact. The last paragraph cites DHCP. It appears to suggest that renumbering tools are a) adequate, and b) adequately deployed. The paper needs to discuss both of these assumptions in detail, particularly since there is a substantial constituency which believes that both assumptions are entirely incorrect. 6 Conclusions The first paragraph cites concerns for routing system scaling. However there is no concern expressed for Internet local providers or users. The paper needs substantial enhancement to consider the breadth of the proposal's effect. In fact I strongly urge than any proposal which attempts major change to the Internet -- as does this one -- be required to offer an operational "environmental impact statement." Equally strongly I suggest that this include a transition plan, as we require for other, equally massive changes. -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker(a)brandenburg.com

1 0

Re: CIDR FAQ
by Arnold Nipper 19 Aug '95

19 Aug '95

Hank Nussbacher wrote: > > On Thu, 17 Aug 1995 00:30:19 +0200 (MET DST) you said: > >Simon Poole wrote: > >> > >> Yakov, if you have data that CIDR is -not- working for new allocations > >> please present it here. > >> > >> Simon > > > >CIDR doesn't work as it should. We had to inject all of the more specifics > >of 194.45/16 cause Sprintlink isn't able to handle CIDR routes correctly. > > Can someone explain this a bit more? This sounds like a showstopper > for CIDR. > Xlink (AS517) was announcing 194.45.0.0/16 via Ebone. There are some networks within this block announced by PSI. Routing table at PSI looks like Mitch Levinn wrote: > > Hi there, > > >I've to second Mitch! Looks like a Sprint problem to me!! Mitch, would you be > >so kind to provide "show ip bgp 194.45.0.0 255.255.0.0 subnet" from the PSI > >box? Unfortunately neither Sprint nor Ebone NOC did anything (since Friday > >morning local time!) but ignoring the problem. I would really appreciate if > >EOT or Ebone NOC would try to fix this problem! > > Here's the output requested (from our MAE-East+ router): > > >show ip bgp 194.45.0.0 255.255.0.0 subnet > BGP table version is 1444840, local router ID is 192.41.177.245 > Status codes: s suppressed, * valid, > best, i - internal > Origin codes: i - IGP, e - EGP, ? - incomplete > > Network Next Hop Metric LocPrf Weight Path > *> 194.45.0.0 38.1.2.10 5 32768 i > *> 194.45.0.0/16 192.41.177.241 0 1239 1800 1755 517 ? > *> 194.45.1.0 38.1.2.10 5 32768 i > *> 194.45.2.0 38.1.2.10 5 32768 i > *> 194.45.3.0 38.1.2.10 5 32768 i > *> 194.45.4.0 38.1.2.10 5 32768 i > *> 194.45.5.0 38.1.2.10 5 32768 i > *> 194.45.6.0 38.1.2.10 5 32768 i > *> 194.45.7.0 38.1.2.10 5 32768 i > *> 194.45.16.0 192.41.177.181 0 3561 1220 ? > > This is just as it was last time the problem surfaced, I > believe. Subnets 0 through 7 are properly being announced through us, > subnet 16 goes to MCI, and the rest to Sprint. > > -Mitch > But Sprintlink was routing >traceroute -g c.psi.net 194.45.41.1 >traceroute to 194.45.41.1 (194.45.41.1), 30 hops max, 40 byte packets > 1 KarlSruhe.Core.xlink.net (193.141.40.252) 2 ms 5 ms > 2 muenchen.core.xlink.net (192.54.104.241) 18 ms 10 ms > 3 Munich-EBS.EBONE.NET (192.121.158.13) 12 ms 13 ms > 4 icm-dc-1-S2/5-1984k.icp.net (198.67.129.17) 210 ms 141 ms > 5 icm-mae-e-H1/0-T3.icp.net (198.67.131.9) 310 ms 253 ms > 6 mae-east.psi.net (192.41.177.245) 254 ms 266 ms > 7 c.psi.net (192.33.4.12) 257 ms 289 ms > 8 192.33.4.1 (192.33.4.1) 227 ms 257 ms > 9 sl-mae-e-F0/0.sprintlink.net (192.41.177.241) 245 ms 250 ms >10 mae-east.psi.net (192.41.177.245) 203 ms 228 ms >11 sl-mae-e-F0/0.sprintlink.net (192.41.177.241) 215 ms 193 ms TT to Sprintlink didn't help. After 4 days still no response. I've fixed this silly routing by announcing all more specifics. > > > >Arnold > > Hank Arnold

2 2

Re: CIDR FAQ
by Hank Nussbacher 18 Aug '95

18 Aug '95

On Thu, 17 Aug 1995 14:57:40 -0700 (PDT) you said: >> >Does that mean that all the internet registries no longer allocate >> >/24 (or longer) prefixes that have nothing to do with the actual >> >Internet topology (these prefixes aka "portable addresses") ? Perhaps >> >folks from various Internet registries would be able to answer this >> >question. >> >> I assign /22s to ISPs. When they use them up I give them another /22. >> Private companies that show a need for a /24 are assigned a /24. >> > >Ah. here is the rub. When you ISP buddies come back, you should ask >them to return the origianal /22 for a /20. That way, the total size >of the routing system stays the same! Great idea. Know ANYONE who does that? The best I can do is give them a /20 (in addition to the original /22) if their growth warrants it. > >-- >--bill Hank

3 2

Re: CIDR FAQ
by rrv＠uiuc.edu 18 Aug '95

18 Aug '95

At 8:47 PM 8/17/95, Gary Wright wrote: >Renumbering isn't necessarily required if the blocks are given out >such that there is room for growth should the smaller IP come back >for more addresses. For example when I allocate individual class >C addresses, I don't give them out consecutively. Initially I leave >at least three unused addresses after the one I allocate. If >someone comes back and needs more, their allocation grows to fill >up the holes. I try to judge who will grow (e.g., a town network) >and who won't (a BBS) and leave my options open as long as possible. One can also accomplish this with a lot less thought by simply making each allocation be as far away from all other allocations as possible within a given CIDR block. For example, allocate xx.xx.0/24 first, xx.xx.128/24 second, xx.xx.64/24 third, xx.xx.192/24 fourth, xx.xx.32/24 fifth, etc. If one only allocates 50% of the space using that kind of an algorithm, then every single prefix can be doubled to become a /23. If one only allocates 25% or the space, then every single prefix can be quadrupled to become a /22. Of course, we'd have to convince the authorities that 25% to 50% utilization of a CIDR block in this manner is a good thing so we could get new /16 or bigger blocks...

2 1

Re: CIDR FAQ
by kwe＠6SigmaNets.com 18 Aug '95

18 Aug '95

At 5:04 AM 8/17/95, Yakov Rekhter wrote: > >In IPv6 there is a notion of "IPv4 compatible" addresses. These are >IPv6 addresses (128 bits) that have IPv4 address as their low order 32 >bits and the rest (96 bits) are zero. ... > >What you said is correct only if hosts use IPv6 addresses that >are not "IPv4 compatible". But transition with hosts that don't have >IPv4 compatible addresses is quite messy. Yakov; If you have an IPv6 capable host, why use "IPv4 compatible" addresses? Why not use an algorithmic translation that includes a provider prefix? It would seem to me that any IPv6 host should have the capability to algorithmically translate its IPv4 address, preferably dynamically. --Kent

2 1

Re: CIDR FAQ
by rrv＠uiuc.edu 18 Aug '95

18 Aug '95

At 4:57 PM 8/17/95, bmanning(a)ISI.EDU wrote: >Ah. here is the rub. When you ISP buddies come back, you should ask >them to return the origianal /22 for a /20. That way, the total size >of the routing system stays the same! If everyone did a clever job of allocation, and the ISP in question had grown quickly enough, you'd be able to expand the that /22 into a /20 at the very same address because the next 3 /22s would still be available. But I've already beaten that horse...

1 0

Re: CIDR FAQ
by Guy T Almes 18 Aug '95

18 Aug '95

At 08:22 AM 8/18/95 IST, Hank Nussbacher wrote: >On Thu, 17 Aug 1995 14:57:40 -0700 (PDT) Bill said: >>> >>> I assign /22s to ISPs. When they use them up I give them another /22. >>> Private companies that show a need for a /24 are assigned a /24. >>> >> >>Ah. here is the rub. When you ISP buddies come back, you should ask >>them to return the origianal /22 for a /20. That way, the total size >>of the routing system stays the same! > >Great idea. Know ANYONE who does that? The best I can do is give them a >/20 (in addition to the original /22) if their growth warrants it. > Hank, I like your idea. At first, you suggested giving the ISP a string of /22s. This could end up having a possibly large number of prefixes assigned to the same ISP. Then Bill suggested growth by requiring an exchange of an old /22 for a new /20. (And the next time requiring an exchange of the new /20 for a newer /18.) This could end up requiring this ISP's customers to renumber more frequently than the customers of its competitors, all due to a possibly quite reasonable judgement call by the registry. Your lastest idea provides an interesting compromise. If the ISP exhausts the initial /22, give them a new /20 and let them keep the /22. This does not achieve Bill's goal of a *constant* number of prefixes, but it does do the following: <> it keeps the growth in the ISP's prefixes logarithmic as a function of its customer base (not as good as constant, but better than linear), <> it allows the registry to grant as big or as little an initial prefix length without biasing the market in favor of one ISP over another, and <> it doesn't require as aggressive a rate of renumbering by customers as Bill's stricter notion. This is probably what many registries do now. The trouble with either your original (string of /22s) idea or Bills (strict exchange with constant number of prefixes) idea is that it puts too much weight on the registry's decision on how big a prefix to grant to a new ISP or an existing ISP in a rapidly growing market. If the registry grants too short a prefix, then address space is wasted. If the registry grants too long a prefix, then: [] under your original idea, routing table entries grow linearly, and [] under Bill's idea, the ISP's customers have to renumber too soon. By growing logarithmically, the registry doesn't have as much hanging on its initial prefix length decision, and the competitive field is more level. Two footnotes: ** as another person noted, you can optimize by leaving gaps around your initial prefix assignment and sometimes collapse blocks of a single ISP, and ** you could still require renumbering, though a little less aggressively than Bill does, by requiring the initial /22 to be returned, say, when the ISP's 4th prefix (a /16) is granted. At any rate, the 'renumbering cloud' hanging over the head of new customers should not depend on their choice of ISP. -- Guy

1 0

NANOG Meeting
by Pam Ciesla 18 Aug '95

18 Aug '95

OOPS! My mistake the NANOG Meeting is will be in PITTSBURG, PA. Pam

1 0

Re: CIDR FAQ
by Hank Nussbacher 18 Aug '95

18 Aug '95

On Thu, 17 Aug 1995 17:01:14 -0700 (MST) you said: >> On Thu, 17 Aug 1995 00:30:19 +0200 (MET DST) you said: >> >Simon Poole wrote: >> >> >> >> Yakov, if you have data that CIDR is -not- working for new allocations >> >> please present it here. >> >> >> >> Simon >> > >> >CIDR doesn't work as it should. We had to inject all of the more specifics >> >of 194.45/16 cause Sprintlink isn't able to handle CIDR routes correctly. >> >> Can someone explain this a bit more? This sounds like a showstopper >> for CIDR. > >I have noticed some similar problems. MCI routing breaks if you provide them >with an identical path at multiple interconnects if it is advertised to them >at equal cost, hence they always like to see MEDs. In regards, a recent announcement (8/11): To All Maintainers of Data in the MCI Routing Registry, Until very recently, ANS's routers have been unable to support the MULTI_EXIT_DISCRIMINATOR (MED) attribute of BGP4. The result of this was that if an Autonomous System (AS) peered with ANS in more than one place, static configuration was required to specify which peer is the preferred exit point from ANS. This need for static configuration was satisfied with the 'advisory: AS690' attribute. ANS has now implemented MEDs in their routers and has already tested it with a few ASs. They have told us that they are willing to turn on MEDs with AS3561 on Tuesday 15 August. This greatly simplifies the 'advisory' attribute needed in the registry. For example, if your current 'advisory' attribute looks like: advisory: AS690 1:3561(11) 2:3561(144) 3:3561(27) 4:3561(147) 5:3561(218) it can now be reduced to: advisory: AS690 1:3561 We do not know which other providers, if any, have arranged to send MEDs to ANS. So, if some of the networks you maintain in the RR are multi-homed to provider(s) which also peer with ANS in more than one place, you would need to talk directly to the other provider(s) to see if the 'advisory' string should change. An example of an 'advisory' attribute for a network that is homed to both MCI and Alternet, with primary service through MCI, and assuming that ANS has not enabled MEDs with AS701, is: advisory: AS690 1:3561 2:701(147) 3:701(144) The RR Users Guide will be updated with this information; it will not contain any more information than this e-mail message. The most recent version of the Users Guide is always available from "ftp://ftp.mci.net/pub/rr/docs/mci-user.txt" (a PostScript version is also available with an extension of '.ps'). MCI is volunteering to change 'advisory' attributes in existing route objects in the MCI RR to the new syntax; ASs other than 3561 *will* be preserved, so the semantic of the 'advisory' will *not* change. We will make this change on Friday morning 11 August. If you have any questions or concerns about this, please tell us before Friday morning by sending a message to 'rr-types(a)mci.net'. Starting Friday morning 11 August, please make sure that all new and updated route objects contain the new 'advisory' string. Thank You. /jws >Dave Hank

1 0