Re: Generic anycast addresses...

On Fri., 31 May 2019, 09:04 Ted Lemon, <mellon@fugue.com> wrote:

> On May 30, 2019, at 3:53 PM, Sander Steffann <sander@steffann.nl> wrote:
>
> I like the scope aspect of Mark's draft. ULA is always organisation or
> site scoped, and should be filtered as such. Anycast that have a different
> scope should have different boundaries. Anycast addresses that have ISP
> scope can cross from the customer's network to the ISP's network, while
> there should be a boundary between that customer's ULA addresses and that
> ISP's ULA addresses (let's assume they both use ULA for this example).
>
>
> I agree that this makes sense in principle.   But I think it’s a lot
> fuzzier than you’re at least allowing for.   As I pointed out previously,
> what “ISP scope means” when you are at a site that’s multi-homed is
> impossible to specify, because there is more than one scope that could be
> called “ISP scope,” and the scopes are disjoint.
>
> Therefore I would prefer not to wait for this seemingly intractable
> problem to be solved before solving the problem that I’m actually trying to
> solve.
>

I don't think a Network Service Provider scope is too ambiguous. Network
Service Provider/customer relationship is a child/parent relationship.

So a customer attached to two different NSPs has two different parents. An
anycast service could be provided by either of them or both e.g. DNS
resolver service.

As with multicast, some scopes can be autoconfigured, others have to be
manually configured when and where the operator considers the boundary to
be. A network service provider knows they are one, and a customer usually
knows clearly that they're not a network service provider.

Regards,
Mark.

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>