Search RPD Archives
[rpd] AnyCast assignments - Update
Mark Elkins
mje at posix.co.za
Tue Nov 18 15:13:48 UTC 2014
Regarding My AnyCast revision - there was some simple wording changes
that Ernest said he'd get to (I gave the changes - it was to update the
Web Site) - but staff were not available.
Still waiting on Ernest?
On Tue, 2014-11-18 at 15:45 +0300, Adam Nelson wrote:
> 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
> 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
>
>
>
> _______________________________________________
> rpd mailing list
> rpd at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
--
Mark James ELKINS - Posix Systems - (South) Africa
mje at posix.co.za Tel: +27.128070590 Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5810 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20141118/5a733f7b/attachment.bin>
More information about the RPD
mailing list