Re: Generic anycast addresses...

[joel jaeggli <[e-mail]>]

On 6/2/19 06:03, Toerless Eckert wrote:
> 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. 

You mean like BGP or are you refering to something else?

> 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.
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>