Re: Generic anycast addresses...

On Fri, 31 May 2019 at 09:47, Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:
>
> On 31-May-19 11:04, Ted Lemon wrote:
> > On May 30, 2019, at 3:53 PM, Sander Steffann <sander@steffann.nl <mailto: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.
>
> That is probably wise. But anyway, if the desired scope of your anycast
> address is set by routing policy, it surely doesn't matter what the prefix
> is? If you support 2001:0db8:f000:baaa:f000:baaa:f000:baaa as an anycast
> address, it's up to you to determine exactly how far out from the user
> that address is filtered (site boundary, ISP boundary, or further).
> Even for multihomed sites, that remains true.
>
> Either that or specify a maximum allowed hop limit.
>
> BTW we did perform a long term experiment with the anycast prefix
> 2002::/16, and some would say that it showed the risk of such things.
>

Well that is a global scope anycast so there is no limit to both the
availability or consequences.

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