> On Feb 25, 2015, at 15:50 , Skeeve Stevens <ske...@v4now.com> wrote:
> 
> 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.

IP runout was well and truly known to be coming more than 20 years ago. That’s 
one of the reasons IPv6 was developed so long ago.

> 
> Please understand, that I am not suggesting giving an ASN to anyone who has 
> no intention of ever multi-homing.

Yes you are. You may not intend to suggest that, but your policy proposal 
wording certainly provides for it.

> 
> 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.

Then propose a policy that does that. The current draft doesn’t. If it has 
sufficient safeguards against turning the ASN registry into a Pez dispenser, 
then I will support it.

> 
> 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.

Nobody is objecting to that. However, that’s not a letter of the law 
interpretation of what you have proposed.

Owen

> 
> 
> 
> ...Skeeve
> 
> Skeeve Stevens - Senior IP Broker
> v4Now - an eintellego Networks service
> ske...@v4now.com <mailto:ske...@v4now.com> ; www.v4now.com 
> <http://www.v4now.com/>
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve <>
> facebook.com/v4now <http://facebook.com/v4now> ;  
> <http://twitter.com/networkceoau>linkedin.com/in/skeeve 
> <http://linkedin.com/in/skeeve>
> twitter.com/theispguy <http://twitter.com/theispguy> ; blog: 
> www.theispguy.com <http://www.theispguy.com/>
> 
> IP Address Brokering - Introducing sellers and buyers
> 
> On Thu, Feb 26, 2015 at 8:36 AM, Dean Pemberton <d...@internetnz.net.nz 
> <mailto:d...@internetnz.net.nz>> 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)
> d...@internetnz.net.nz <mailto:d...@internetnz.net.nz>
> 
> To promote the Internet's benefits and uses, and protect its potential.
> 
> On Thu, Feb 26, 2015 at 12:11 PM, Skeeve Stevens <ske...@v4now.com 
> <mailto:ske...@v4now.com>> 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
> ske...@v4now.com <mailto:ske...@v4now.com> ; www.v4now.com 
> <http://www.v4now.com/>
> Phone: 1300 239 038; Cell +61 (0)414 753 383 
> <tel:%2B61%20%280%29414%20753%20383> ; skype://skeeve <>
> facebook.com/v4now <http://facebook.com/v4now> ;  
> <http://twitter.com/networkceoau>linkedin.com/in/skeeve 
> <http://linkedin.com/in/skeeve>
> twitter.com/theispguy <http://twitter.com/theispguy> ; blog: 
> www.theispguy.com <http://www.theispguy.com/>
> 
> IP Address Brokering - Introducing sellers and buyers
> 
> On Thu, Feb 26, 2015 at 8:03 AM, Owen DeLong <o...@delong.com 
> <mailto:o...@delong.com>> wrote:
> 
> > On Feb 24, 2015, at 22:47 , Raphael Ho <raphael...@ap.equinix.com 
> > <mailto:raphael...@ap.equinix.com>> 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
> sig-policy@lists.apnic.net <mailto:sig-policy@lists.apnic.net>
> http://mailman.apnic.net/mailman/listinfo/sig-policy 
> <http://mailman.apnic.net/mailman/listinfo/sig-policy>
> 
> 
> *              sig-policy:  APNIC SIG on resource management policy           
> *
> _______________________________________________
> sig-policy mailing list
> sig-policy@lists.apnic.net <mailto:sig-policy@lists.apnic.net>
> http://mailman.apnic.net/mailman/listinfo/sig-policy 
> <http://mailman.apnic.net/mailman/listinfo/sig-policy>
> 
> 
> 

*              sig-policy:  APNIC SIG on resource management policy           *
_______________________________________________
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Reply via email to