[address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)
- Next message (by thread): [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Elvis Velea
elvis at velea.eu
Tue Oct 1 00:06:58 CEST 2013
Hi Tore, On 9/30/13 9:02 PM, Tore Anderson wrote: > * Gert Doering >> On Mon, Sep 30, 2013 at 06:41:14PM +0200, Tore Anderson wrote: >>> Q: How would that work? >>> A: We could end up with two levels of RIPE NCC membership, e.g. "full" >>> like we have today, and "associate". Both would be fully-blown LIRs, but >>> to keep the operational overhead in NCC billing/finance low, the >>> membership fee for these "associate" members would be charged by the NCC >>> to the full members who are sponsoring them (just like with PI). >> >> I'm not exactly sure what the difference between an "associate member" >> and today's "consumer of resources provided by a sponsoring LIR" would >> then be, except for the title on the contract. On the contrary, some >> enterprises just don't want to deal with the RIPE NCC if they can make >> a contract with their friendly neighbouring LIR instead... > > The difference would be that an "associate member" (which is just an > idea, and outside the scope of APWG anyway) would be an LIR, and would > therefore be able to assign address space to its customer in turn. again, assignments are removed from the proposed text. they will be able to sub-allocate. I agree that we may need to give this 'sort of IR' a name, associate member doesn't sound right though. Keep firing suggestions ;) > > PI holders currently cannot assign address space to their customers, and > that's what I understand this proposal to be all about changing, but it > does it in a way that defines a new "breed" of End User who a) does not > at all fit the original definition of an End User, while b) does > completely fit the definition of an Internet Registry. Put it another > way, the new (1st level) type of End User created by the proposal > appears to me to be an LIR in all but name. It will probably be some kind of IR, just not an LIR nor an End User. > > So what I'm thinking is that it's better to call a spade a spade as far > as address policy go, and instead have the NCC/AGM/Board decide exactly > how they want to go about charging for the different flavours of spades. It's not really a spade, that organisation will be able to use the address space or sub-allocate (parts of) it to other organisations. However, these will have the same right (use or sub-allocate). What do we do then? call everyone an 'associate' ? > > But that's just my €0.02. Like I said earlier, this should not be > mistaken for opposition to the current proposal, just a suggestion. > >> So I'm not sure it's worth abandoning the established concept of sponsoring >> LIR right away (especially since doing away with it would affect IPv4 PI >> as well...). It wouldn't make a difference anyway :-) - if we want to >> give people the option to take a /48 because it's big enough for them, >> we'd then still have "two standard sizes"... > > Or we could simply tell the requesters to pick their favourite number > between 28 and 49... as long as policy says it's should be possible to > extend up to and including /29 it doesn't really matter what they start > out with as far as keeping delegations aggregated go (and routing is > another matter entirely). It's up to /29 for LIRs. How did you get to the numbers 28 or 49? It's either /48 if the organisation is sure that they will not need more; or a /32 if they do plan to sub-allocate to other customers. Adding intermediary numbers does not make any sense, allowing intermediary numbers may cause all kinds of problems: - billing issues, if at some time the AGM will decide to bill based on the size (as it used to do with IPv4 in the past) - filtering issues - aggregation issues >> So, yes, another avenue could be "abandon /48 assignments/allocations", >> but *that* brings up another can of worms (what about an enterprise that >> has 5 locations that all have local ISP upstreams and want to do BGP >> multihoming? 5x /48 suits them well today, 1x /32 with someone blocking >> more-specifics from that because no site is announcing the /32 aggregate >> would not be that good). > > But that's the route6 object, not the inet6num. If someone is filtering > on the inet6num without accepting more specifics they're already asking > for trouble (their users would surely complain about lack of > connectivity to the more-specifics inside 2a02:26f0::/32, for starters). I already answered in my previous message. See 5.2.1 from the proposed text. > > Tore > Elvis
- Next message (by thread): [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]