[address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED

Dear all,

I also support RIPE NCC's initiative for dealing with those ALLOCATED 
PI/UNSPECIFIED assignments.

By the way, our company holds one of these PIs in KPN's /16. And as far 
as we are concerned an annual fee of 50 EUR would be okay, too.

Kind Regards
Stefan Schiele


Am 18.08.2016 um 11:36 schrieb herve.clement at orange.com:
>
> Dear all,
>
> From my point of view I support this initiative of the RIPE NCC as it 
> brings more clarity and simplicity regarding IPv4 resources management.
>
> Hervé Clément
>
> Orange
>
> -----Message d'origine-----
> De : address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] De 
> la part de Ingrid Wijte
> Envoyé : vendredi 5 août 2016 15:41
> À : Gert Doering; Randy Bush
> Cc : Larisa Yurkina; address-policy-wg at ripe.net
> Objet : Re: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED
>
> Dear colleagues,
>
> >>> Also, it might lead to deaggs (Markus' case) where a /14 that was
>
> >>> originally "in one LIR" would be "3x /16, plus some smaller
>
> >>> fragments in the LIR" and "lots of /24 PI managed by the NCC" now -
>
> >>> so the /14 won't get a ROA, and he'll have to announce more-specifics.
>
> >> lemme see if i get this.  to have the owner registration correct,
>
> >> some address space will have to be broken up and owned by multiple
>
> >> IRs, thus fragmenting routing? i like correct registration, but the
>
> >> commons has become pretty polluted.
>
> The main issue that we (the WG and the RIPE NCC) are trying to resolve 
> is the lack of clarity around the status and rights of these 
> assignments. It’s not necessarily the case that the End User 
> registration is incorrect. In many cases LIRs have put a lot of effort 
> into keeping this information up to date.
>
> If there is a /16 “ALLOCATED UNSPECIFIED” block that contains "real" 
> Provider Independent assignments, that /16 would indeed be split in 
> order to carve out that assignment. The LIR would end up with multiple 
> PA allocations instead of one /16. The PI resource holder would be 
> able to decide who their sponsoring LIR should be. It is possible that 
> they would remain with that same LIR, or they could move to another 
> sponsoring LIR and take their PI assignment with them. If the resource 
> holder is an LIR themselves, the PI assignment could be registered 
> under their own LIR account.
>
> This means that route and domain objects would need to be updated. 
> It’s also relevant to mention that several LIRs already allow for more 
> specific routes for the assignments.
>
> The LIRs will be able to request a new ROA for their remaining blocks. 
> The sponsoring LIR can request a ROA on behalf of the PI resource 
> holder, or the PI holder can do that themselves if they wish.
>
> I hope this answers your questions.
>
> Ingrid Wijte
>
> RIPE NCC
>
> > I leave the definite answer to Ingrid to answer.
>
> >
>
> > My understanding of "normal" NCC<->LIR stockkeeping is that PI is
>
> > never living inside blocks that "belong" to a given LIR.  So, the LIR
>
> > would never be able to get a ROA covering PI space.
>
> >
>
> > For some of these "old" blocks, there is a /16 which covers regular
>
> > LIR/PA space, and "not real PI" space, and the LIR can get a ROA that
>
> > covers their PA space, and also these "not real PI" blocks (because
>
> > according to the NCC records, the /16 "belongs" to the LIR).
>
> >
>
> >  From an aggregation PoV, this is ok-ish - but from a routing security
>
> > PoV, I wonder if that's what we want (the "not real PI" block might be
>
> > routed totally elsewhere now).
>
> >
>
> >
>
> >>> So, to answer your question: for those "swampy PI", it would alter
>
> >>> their rights (contracts according to 2007-01), costs (50 EUR/year)
>
> >> whoops.  that's gonna cause unhappiness.
>
> > Dunno.  We (the RIPE community and the NCC) rolled out 2007-01 to all
>
> > the other PI holders, and the amount of unhappiness was not very big.
>
> >
>
> > Those cases that I was involved with my "LIR admin-c" hat on, PI
>
> > holders seemed to be happy to have a clear contract with a known
>
> > entity (us), and the assurance that this would ensure that nobody else
>
> > could make claims to their address space.
>
> >
>
> > Gert Doering
>
> >          -- assorted hats
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160822/53ed5d8a/attachment.html>