Subject: [magma] IPv6 anycast usage API?

From: Pekka Savola <[email-masked]>
Date: Wed, 8 Jan 2003 21:25:43 +0200 (EET)

Hello,

Has anyone given any thought to whether there should be any (IPv6) anycast
addressing API for _applications_?

As background, anycast support has usually been implemented either using:

 1) an "anycast" flag when configuring an address with system
administration -level tools like "ifconfig", or

 2) some vendor-specific API which applications can use to signal that
they would like to join an anycast "group".  As you may note, this is very
similar to how multicast works -- which is natural because the model is
similar.

I know a couple of implementations: most do 1), unofficial anycast support
for Linux does 2).  I'd be interested if there are other ways to make
anycast addressing usable.

The advantage of 2) is that it gets closer to applications: when an
application using an anycast address (e.g. DNS server software) e.g.  
crashes, the anycast address automatically gets removed.  Of course, there
are still failure modes, but I believe this closer to the usage model if
we want anycast to be usable for applications, and want to use it
robustly.

Of course, for some cases, 1) is also useful -- but they are not 
exclusive, I think.

Comments are very much welcome.  Should we try to document some simple API
for anycast for applications, for example?  

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: Brian Haberman <[email-masked]>
Date: Wed, 08 Jan 2003 16:30:02 -0500

Pekka,
      An anycast API would be nice, if we can decide on what
model we want to follow.  One possibility is to follow the
multicast model and that is what Dave Thaler and I defined
in draft-haberman-ipngwg-host-anycast-01.txt.  And then
Erik Nordmark and I put forth a draft that re-used the
Return Routability portion of MIPv6 for anycast.  That is
in draft-haberman-ipv6-anycast-rr-00.txt.  Depending on
which model is used, the API would be vastly different.

      What I would like to see is some discussion on these
proposals and how they address the points put forth in
draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt.  I think
this needs to occur before we develop an API.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Wed, 08 Jan 2003 16:30:02 -0500

Pekka,

Regards,
Brian

---

From: Pekka Savola <[email-masked]>
Date: Wed, 8 Jan 2003 23:44:25 +0200 (EET)

> this needs to occur before we develop an API.

It seems that you are suggesting that we flesh out the problems in anycast
usage (anycast-analysis, anycast-rr) first.

That's sensible, I guess.  But it may also be a dead-end (at least for
some time).

I don't think it's _required_ to have the infrastructure, even as much as 
in host-anycast-01, to do the first stage of API, if that seems to be the 
way to go.

Basically, what I was proposing, was a way to join or leave anycast group,
which would add or remove an anycast address from an interface.  Nothing 
more: everything that works _now_.  (What happens then is what happens 
when you would configure it as an anycast address manually.)

Of course, such an API would probably have to be augmented or even
re-thought when/if we figure out we need to change the anycast model (like
presented in host-anycast-01, or required by anycast-analysis).

That is, I was thinking of quite high-level primitives.  I didn't want to 
get stuck on how you manage to use anycast e.g. with TCP yet, or how to 
make anycast globally usable :-).

...

So, I guess there are different views on the paths that could be pursued.  
I wonder if there are folks that feel some vague abstraction layer API
could be useful now?

---

From: Pekka Savola <[email-masked]>
Date: Wed, 8 Jan 2003 23:44:25 +0200 (EET)

...

---

From: Brian Haberman <[email-masked]>
Date: Wed, 08 Jan 2003 17:00:33 -0500

> usage (anycast-analysis, anycast-rr) first.

I would say that it would help if we understood what the underlying
protocols would be before we develop an API.  For example, if we
use the mcast model, then extending the setsockopt() call to allow
an app to join an anycast group would seem reasonable.  However, if
we look at an anycast member participating in the routing system
in order to originate the host-route for the anycast address, the
setsockopt() may not be the way to go.

> That's sensible, I guess.  But it may also be a dead-end (at least for

It may be.  I would like someone to put together a doc that
describes the usage of anycast in v6 so that we can data
points on building the protocols.

> presented in host-anycast-01, or required by anycast-analysis).

Exactly.  That is why I am not sure if we should put the API
first when we don't know the model.

> make anycast globally usable :-).

Understood and agree.

> I wonder if there are folks that feel some vague abstraction layer API

I would certainly like to hear others opinions.  However, the magma
list may not be the most suitable place for it.  We went around for
awhile on the charter to ensure that only the group management
aspects of anycast were in scope.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Wed, 08 Jan 2003 17:00:33 -0500

Understood and agree.

Regards,
Brian

---

From: Pekka Savola <[email-masked]>
Date: Thu, 9 Jan 2003 17:22:49 +0200 (EET)

[...]
> setsockopt() may not be the way to go.

I agree here -- _provided_ that we're looking for a ways for an app to
originate a host-route, or whatever.  I wasn't looking at that far.  The
same results you would get from configuring an address with anycast flag.

(Of course, proper analysis whether that satisfies enough criteria that 
it's actually useful for deployment would be nice.)
 
[...]

---

From: Pekka Savola <[email-masked]>
Date: Thu, 9 Jan 2003 17:22:49 +0200 (EET)

[...]