Re: Generic anycast addresses...

[Toerless Eckert <[e-mail]>]

As you are repeating your argument to make your case, let me
respectfully also disagree again, but also suggest what IMHO would be
a safer and more flexible approach.

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. 
That would get a us a lot further proliferating benefits of anycast.
If defined appropriately rich to indicate scope/zone for example, IMHO we would
solve the scope problem as well without having to creating more and
more specialized address spaces. 

There are also other policies for redundant IP addresses
than anycast (nearest member). For example, what i called
"prioritycast", where you want the current highest-priority member of
the group to be the destination. And in a time where delay becomes for
many applications as important if not more so than throughput, "nearest"
could have different bandwidth vs. delay interpretations and routing
policies.

I can see how there will be an ongoing demand to support lazy, oops:
easy "discovery" options with well-known addresses, but lets not assume
that we should or could come up with a generally applicable better working
address encoded scoping solutions than we did in the past or assume that
one specific form of redundany (IGP SPF "shortest") is the only necessary policy.

Aka: I think for each application that needs one or a limited number
of well-known addresses an IANA allocation could be given from a TBD
larger block of well-known "functional unicast addresses" for which
the default policy is not to route, and the policy for each allocation
is to define (via an RFC) how to route/forward it. Effectively this would
mean this block must not be forwarded via aggregated routes, because the
route policy of each allocation should support to be differernt: notion
of scope/zones/anycast/priority/....

This would allow Ted to come up with a routing policy for the
adress(es) he wants to have and his definition of what an appropriate
"scope/zone" is, without us (IETF) having to agree that that is a universally
reusable notion of scope/zone.

The only downside for an app like the one from Ted would be that he
wouldn't get on riding on the default route for free but that whoever
wants to use the address has to explicitly add the right routes and routing
policy. Of course this may only be true in the future depending of which
address space we carve out this address space from - if its carved out
of existing global address space it would be routed via default-route by
legacy equipment. 

Cheers
    Toerless

On Sun, Jun 02, 2019 at 10:35:00AM +1000, Mark Smith wrote:
> I think we need a formal, multi-scoped anycast address space.
> 
> Anycast also has enough properties in common with multicast that I think it
> should be more than just a configured special case address within the
> unicast address space. I think it should be a distinct class in between
> unicast and multicast.
> 
> Unicast: 1:1
> Anycast: 1:Any
> Multicast: 1:Many
> 
> 
> IPv6 Formal Anycast Addresses and Functional Anycast Addresses
> 
> https://tools.ietf.org/id/draft-smith-6man-form-func-anycast-addresses-00.txt
> 
> 
> Regards,
> Mark.