Dean, You are quoting an RFC from 1996 (19 years ago)? What next, the Old Testament? Thou shalt be multi-homed?
I don't think this RFC ever envisioned the IP runout and that networks hosted by businesses themselves (of any size) would need multi-homing and in the reading of this, you could make an argument that no-one needs an ASN and that all their upstreams could host their portable space for them. Please understand, that I am not suggesting giving an ASN to anyone who has no intention of ever multi-homing. I am wanting to policy to reflect that if a network operator wants to design their network for multi-homing, that they should be able to, with no requirement to immediately multi-home. At no point did I say 'never' multi-home, or no intention of multi-homing.... the intention should be there. I'm asking that the policy reflect an operators choice to decide how they manage their networks should they choose to do it that way. ...Skeeve *Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service [email protected] ; www.v4now.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/v4now ; <http://twitter.com/networkceoau> linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com IP Address Brokering - Introducing sellers and buyers On Thu, Feb 26, 2015 at 8:36 AM, Dean Pemberton <[email protected]> wrote: > Actually the RFC makes this clear. > > There is clear guidance within RFC1930 for this which is marked as "BEST > CURRENT PRACTICE". Please someone let me know if I've missed an > obsolescence here. > > All of the situations you are talking about are described as "rare and > should almost never happen". If you believe that the RFC is wrong and no > longer constitutes best practice, then engage in the IETF community and try > and fix this at the source rather than using RIR policy to justify a > departure from documented current best practice. > > > > 5.1 Sample Cases > > * Single-homed site, single prefix > > A separate AS is not needed; the prefix should be placed in an > AS of the provider. The site's prefix has exactly the same rout- > ing policy as the other customers of the site's service > provider, and there is no need to make any distinction in rout- > ing information. > > This idea may at first seem slightly alien to some, but it high- > lights the clear distinction in the use of the AS number as a > representation of routing policy as opposed to some form of > administrative use. > > In some situations, a single site, or piece of a site, may find > it necessary to have a policy different from that of its > provider, or the rest of the site. In such an instance, a sepa- > rate AS must be created for the affected prefixes. This situa- > tion is rare and should almost never happen. Very few stub sites > require different routing policies than their parents. Because > the AS is the unit of policy, however, this sometimes occurs. > > * Single-homed site, multiple prefixes > > Again, a separate AS is not needed; the prefixes should be > placed in an AS of the site's provider. > > * Multi-homed site > > Here multi-homed is taken to mean a prefix or group of prefixes > which connects to more than one service provider (i.e. more than > one AS with its own routing policy). It does not mean a network > multi-homed running an IGP for the purposes of resilience. > > An AS is required; the site's prefixes should be part of a > single AS, distinct from the ASes of its service providers. > This allows the customer the ability to have a different repre- > sentation of policy and preference among the different service > providers. > > This is ALMOST THE ONLY case where a network operator should > create its own AS number. In this case, the site should ensure > that it has the necessary facilities to run appropriate routing > protocols, such as BGP4. > > -- > Dean Pemberton > > Technical Policy Advisor > InternetNZ > +64 21 920 363 (mob) > [email protected] > > To promote the Internet's benefits and uses, and protect its potential. > > On Thu, Feb 26, 2015 at 12:11 PM, Skeeve Stevens <[email protected]> wrote: > >> Owen, >> >> But who determines 'if they need one' ? Them, or you (plural)? >> >> I believe they should be able to determine that they need one and be able >> to get one based on that decision - not told how they should be doing their >> upstream connectivity at any particular time. >> >> >> ...Skeeve >> >> *Skeeve Stevens - Senior IP Broker* >> *v4Now - *an eintellego Networks service >> [email protected] ; www.v4now.com >> >> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve >> >> facebook.com/v4now ; <http://twitter.com/networkceoau> >> linkedin.com/in/skeeve >> >> twitter.com/theispguy ; blog: www.theispguy.com >> >> >> IP Address Brokering - Introducing sellers and buyers >> >> On Thu, Feb 26, 2015 at 8:03 AM, Owen DeLong <[email protected]> wrote: >> >>> >>> > On Feb 24, 2015, at 22:47 , Raphael Ho <[email protected]> >>> wrote: >>> > >>> > All, >>> > >>> > I¹m having an offline discussion with Aftab, basically the issue he¹s >>> > trying to address is that new ISPs in small countries/cities may not >>> meet >>> > the day 1 requirements for an ASN, but however should be eligible since >>> > they will require an ASN to peer/multihome at some point in the future >>> > (which I do agree) >>> >>> What is the disadvantage for them to get the ASN later, when they >>> actually need it? >>> >>> > Currently they all have to "commit fraud² in order to get an ASN, and I >>> > guess some religion takes that more seriously than others. >>> >>> They only have to commit fraud if they are determined to get an ASN >>> before they need one. >>> >>> > Would we the proposal be acceptable if we reworded the proposal to say >>> > something on the lines of >>> > >>> > ³Eligible LIRs with APNIC Assigned Portable addresses are also eligible >>> > for as ASN²? >>> >>> I think “an ASN” rather than “as ASN”, but I’d need to better understand >>> why they need one >>> ahead of time. What’s wrong with getting the ASN when you need it? >>> >>> Owen >>> >>> >>> * sig-policy: APNIC SIG on resource management policy >>> * >>> _______________________________________________ >>> sig-policy mailing list >>> [email protected] >>> http://mailman.apnic.net/mailman/listinfo/sig-policy >>> >> >> >> * sig-policy: APNIC SIG on resource management policy >> * >> _______________________________________________ >> sig-policy mailing list >> [email protected] >> http://mailman.apnic.net/mailman/listinfo/sig-policy >> >> >
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list [email protected] http://mailman.apnic.net/mailman/listinfo/sig-policy
