Re: Generic anycast addresses...

[Mark Smith <[e-mail]>]

On Sun., 2 Jun. 2019, 23:31 Nick Hilliard, <[e-mail]> wrote:

> Toerless Eckert wrote on 02/06/2019 14:03:
> > IMHO, it would be lovely to primarily think of standardizing whats
> > IMHO been most missing piece for more proliferation of anycast, and
> > thats an appropriate prototol for anycast members to signal their
> membership.
>
> as an observation, this would introduce host-level state into the
> network, which has scalability consequences.
>

This is a well understood problem, and is called out in RFC 1546.

This issue would be the same one created by ES-IS, except that ES-IS has
all hosts inject their addresses into the routing domain (see RFC 995).
That was designed in the mid-1980s. So if it was a solvable problem then,
it is a much more easily solved problem now given processing and memory
advances since.

Of course, the solution is well known, being route summarisation or
aggregation (and solved for IS-IS with Level-1 levels).

>From my draft,

https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-00

"Forwarding towards anycast addresses is the same as forwarding
   towards unicast addresses, which uses the longest match rule BCP
198 <https://tools.ietf.org/html/bcp198>
   [RFC7608 <https://tools.ietf.org/html/rfc7608>].  Longest match
forwarding facilitates summarisation of
   forwarding information, where a single more general forwarding route


Smith                    Expires April 25, 2019                 [Page 8]

------------------------------

  <https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-00#page-9>Internet-DraftIPv6
Formal And Functional Anycast Addresses  October 2018


   can summarise a number of more specific forwarding routes.
   Summarisation saves entries in forwarding tables outside of the
   summarised forwarding domain, provides simpler destination based
   filtering for security purposes, and facilitates easier destination
   address based traffic analysis.

   The use of route summarisation with anycast addresses effectively
   creates an anycast domain that is being identified and summarised by
   the anycast summary route.  Outside of the anycast domain, a single
   summary route exists, covering all anycast addresses within the
   domain.  Within the anycast domain, individual routes for individual
   anycast addresses exist.

   When designing a new Anycast Identifier field format and structure,
   the following guidelines should be followed.  These guidelines should
   allow a set of more specific anycast "routes to be summarised as well
   as improving operator usability.



"Note that this guildline should not take


Smith                    Expires April 25, 2019                 [Page 9]

------------------------------

  <https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-00#page-10>Internet-DraftIPv6
Formal And Functional Anycast Addresses  October 2018


      precedence over any previous measures to faciliate more specific
      anycast route summarisation."




"External to the anycast domain, the
      identifying 64 bit prefix can be used to create a single summary
      route for the anycast function or service identifier space, which
      will help routing scaling for anycast functions or services."



Regards,
Mark.



> Nick
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>