Re: Generic anycast addresses...

[Mark Smith <[e-mail]>]

On Sun., 2 Jun. 2019, 23:03 Toerless Eckert, <[e-mail]> wrote:

> As you are repeating your argument to make your case,


What am I supposed to do when people ask about things already covered in my
draft?

Here's the link again.

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


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.
>

>From my draft,

Hmm, there
   really needs to be any "Anycast Listener Discovery" protocol similar
   or same as MLD.).



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.
>