Re: Generic anycast addresses...

[Toerless Eckert <[e-mail]>]

On Mon, Jun 03, 2019 at 10:07:12AM +1000, Mark Smith wrote:
> 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.

I also think we learned a lot more about possible policy parameters to
direct the desired routing for such an address. It likely also needs
to include ome way to ask for allocation of an address.

Aka: Yes, we know a lot more, but if we want to make it a lot better
than what we would have done 20..30 years ago, we still need to brainstorm
agree on several aspects.

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

You can only aggregate when the policies actually align, so i would not
in general bet that aggregation is going to be so important. I would
rather count on the total number of required anycast addresses to be
small enough to be easily supported without aggregation.

> >From my draft,

[..]

Thanks, probably a lot more details to be discussed easier
offline/in-person.

Cheers
    Toerless
> 
> 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
> 
>   <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
> > --------------------------------------------------------------------
> >

-- 
---
[e-mail]