[rpd] AnyCast assignments - Update

[Adam Nelson]

I'm writing this up for the meeting right now and have noted:

1. There are 2 replies in support of the proposal.
2. There hasn't been a new draft to address some of the concerns brought
up.  Is one forthcoming?

Cheers,
Adam

--
Kili - Cloud for Africa: kili.io
Musings: twitter.com/varud <https://twitter.com/varud>
More Musings: varud.com
About Adam: www.linkedin.com/in/adamcnelson

On Sat, Nov 8, 2014 at 9:28 AM, Frank Habicht <geier at geier.ne.tz> wrote:

> Hi,
>
> sorry to come pretty late with this, but maybe better now than never (or
> later)...
>
> There are 2 ways for anycast deployments:
> 1. announce and see what happens
> 2. announce and at some locations limit the scope of the announcements to
> only directly peering networks (with the well-known NO_EXPORT community).
>
> By using the 2nd method, some anycast operators differentiate between their
> "global nodes" and "local nodes".
> see also: http://ftp.isc.org/isc/pubs/tn/isc-tn-2003-1.txt
>
> When 2 networks AS1 and AS2 are both connected (and preferring) local
> nodes, they will carry the anycast prefix with NO_EXPORT in their network.
>
> A common customer AS3 that is multihomed to both AS1 and AS2 and receiving
> "full BGP table" from them, will not receive the anycast prefix. If AS3
> doesn't use a default, they will not reach the anycast service.
>
> The original:
> http://www.merit.edu/mail.archives/nanog/2005-10/msg01226.html
> Fix by RIPE NCC ("K"):
> http://meetings.ripe.net/ripe-52/presentations/ripe52-dns-kroot-anycast.pdf
>
> To avoid this, anycast operators have added an announcement for the
> covering /23 from the global nodes. This will always be announced without
> NO_EXPORT community, and will thus be visible and reachable to everyone.
>
>
> I think the same can be expected of anycast operators using this proposed
> policy. Therefore I suggest we give them the option to request and receive
> either /24 or /23 - their choice.
> In IPv6 I also suggest to optionally assign a bigger block than /48.
> A /47 would suffice but I guess we don't want to split the nibble into
> bits ;-)
>
> So I propose to replace every instance of "/24" with "/23 or /24" and
> replace every instance of "/48" with "/44 or /48"  - or maybe "/44 up to
> /48".
>
> Meaning anycast operators can choose which one they request, and they can
> get these according to their request.
>
> Sorry for bringing this up that late.
>
> Frank
>
>
>
> On 11/4/2014 12:06 PM, Mark Elkins wrote:
> > I'm happy to make changes along the lines of what Nishal suggested...
> > that is:
> >
> > Replace:
> > These resources must
> > be used for the sole purpose of anycasting web or authoritative DNS
> > servers as described in BCP126/RFC 4786
> > (http://www.ietf.org/rfc/rfc4786.txt) or for GPRS Roaming Exchange.
> >
> > With:
> > These resources must be used for the sole purposes of providing anycast
> > services.
> >
> >
> > I have been trying to have Ernest update the website - he may have
> > malaria again.
> >
> > On Mon, 2014-10-20 at 21:45 +0200, Mark Elkins wrote:
> >> On Mon, 2014-10-20 at 22:11 +0300, Ernest wrote:
> >>>>> 3) Proposal
> >>>>> AFPUB-2012-V4-001 is modified from the original version to the
> >>>>> following version:
> >>>>> ...........................................................
> >>>>> 1. Summary of the problem being addressed by the policy proposal
> >>>>> This proposal allows an organization to receive an IPv4/IPv6
> >>>>> allocation or assignment and an AS Number purely for anycast or GPRS
> >>>>> Roaming Exchange (GRX) usage.
> >>>>>
> >>>>> 2. Summary of how this proposal addresses the problem
> >>>>> This proposal allows the use of:
> >>>>> a. One (1) /24 of IPv4 for anycast services from a PA allocation of
> >>>>> an LIR or direct end-user assignment.
> >>>>> b. One /48 of IPv6 for anycast services from an IPv6 LIR allocation
> >>>>> or direct end-user assignment.
> >>>>> c. An AS Number for anycast purposes.
> >>>>
> >>>> let me explain the second request. the policy, as is worded, is
> >>>> potentially ambiguous.  hostmasters _may_ be tempted to say that,
> >>>> as per policy, they have satisfied the requirement to allocate
> >>>> one, and only one prefix for anycast purposes, to an
> >>>> organisation, when, a forward thinking organisation might wish to
> >>>> have more than one anycast cloud.  while having one prefix, is
> >>>> obviously better than zero, it would be _wrong_ to limit this to
> >>>> just one anycast cloud.
> >>>>
> >>>> so, while the current policy doesn't _disallow_ more than a
> >>>> single allocation, it's not clear (i think) to the hostmaster
> >>>> team, that more than one allocation might be allowed. (i guess,
> >>>> the other way of looking at this, is that there is no requirement
> >>>> to _change_ policy if, there is acknowledgement from the
> >>>> hostmaster team that they understand this - perhaps we can get
> >>>> them to comment here.  the task of determining valid usage will
> >>>> still be up to the hostmasters of course)
> >>>
> >>> As there are no explicitly indicated limitations in the current
> >>> policy, we implemented this such that an organization can request
> >>> and be granted one /24 *per request*. The frequency of the anycast
> >>> requests however (from the same organization) is unlimited per our
> >>> interpretation.
> >>>
> >>> While reading through the new proposal - we also interpret it such
> >>> that one /24 v4, one /48 v6 prefix and one ASN will be assigned with
> >>> *each* anycast request from the same organization, and there is no
> >>> limit on the number of times the same org can request such resources.
> >>
> >> Which should mean there is nothing wrong with the wording!
> >>
> >> _______________________________________________
> >> rpd mailing list
> >> rpd at afrinic.net
> >> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
> >
> >
> >
> > _______________________________________________
> > rpd mailing list
> > rpd at afrinic.net
> > https://lists.afrinic.net/mailman/listinfo.cgi/rpd
> >
>
> _______________________________________________
> rpd mailing list
> rpd at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20141118/768e42dd/attachment.html>