headers
Pekka Savola | 8 Jan 2003 20:25
Picon

IPv6 anycast usage API?

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
(Continue reading)

Permalink | Reply | 4 comments |
headers
Brian Haberman | 8 Jan 2003 22:30
Picon

Re: IPv6 anycast usage API?

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

Pekka Savola wrote:
> 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
(Continue reading)

Permalink | Reply | 3 comments |
headers
Pekka Savola | 8 Jan 2003 22:44
Picon

Re: IPv6 anycast usage API?

On Wed, 8 Jan 2003, Brian Haberman wrote:
>       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.

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.)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Brian Haberman | 8 Jan 2003 23:00
Picon

Re: IPv6 anycast usage API?

Pekka Savola wrote:
> On Wed, 8 Jan 2003, Brian Haberman wrote:
> 
>>      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.
> 
> 
> It seems that you are suggesting that we flesh out the problems in anycast
> 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.

>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pekka Savola | 9 Jan 2003 16:22
Picon

Re: IPv6 anycast usage API?

On Wed, 8 Jan 2003, Brian Haberman wrote:
[...]
> > It seems that you are suggesting that we flesh out the problems in anycast
> > 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.

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

[...]

--

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Permalink | Reply | 0 comments |
headers
Brian Haberman | 9 Jan 2003 16:33
Picon

MAGMA WG Last Call: draft-ietf-magma-igmpv3-and-routing-04.txt

All,
      This is the start of a MAGMA working group last call on the
IGMPv3/MLDv2 and Multicast Routing Protocol Interaction draft as
an Informational document.  The last call period will end on
Friday, January 24th.  Substantive comments should be directed
to the MAGMA mailing list.  Editorial comments should be directed
to the authors.

Regards,
Brian & Bill
Permalink | Reply | 0 comments |
headers
Karen Kimball | 10 Jan 2003 00:55
Picon

IGMP MIB inputs

Hello, Everyone,

In reviewing the proposed IGMP MIB, there are a few areas that,
while described for routers, also would be meaningful for IGMP 
snooping switches. A few minor modifications or additional 
considerations could aid this more general use.

Specifically, while for routers the network interface (subnet) and 
physical port are one and the same, on switches there can be multiple 
port interfaces for a given network interface. Some of the proposed 
objects for interfaces would be more useful if they were per-physical
-port and not just per-subnet. For instance, the Cache Table could
provide more information as a per-port table when implemented on a
switch (and there would be no difference in the information returned
if implemented on a router).

Could we consider a naming convention that allows this? While switch 
vendors could lump all of their applicable ports together when 
returning an interface object, this would sometimes result in more 
refined information being lost.

On to the comments for the proposed MIB.

1) igmpInterfaceStatus

   Although this is of type "RowStatus," it is being used as a 
   configuration object. I believe that the label	  

     igmpInterfaceState
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bill Fenner | 12 Jan 2003 23:07
Picon

Re: getsockopt for full-state source filter API


>    After exchanging a few emails with Linux kernel maintainters for network
>code, I realised that they too preferred getsockopt & setsockopt for full-
>state API over ioctls.

This is a Linux implementation detail.  The implementation of getsockopt()
in BSD 4.4 and earlier did not pass the user data to the protocol layer,
so the only information the protocol layer can be guaranteed to have
is the optname (e.g. IP_ADD_MEMBERSHIP).  Thus, a portable API cannot
assume that the data in the buffer the user passed to getsockopt() is
available to the protocol.

We considered using setsockopt() for setting the full-state, and ioctl()
for retrieving the full-state, but decided that it would be better to
have a consistent set/get API.  Since getsockopt()'s limitations required
us to use ioctl() for get, we use ioctl() for set too.

  Bill
Permalink | Reply | 523 comments |
headers
v.kulkarni | 12 Jan 2003 18:23
Picon

getsockopt for full-state source filter API

Dear Dave, Bill & Bob,

    Last week, I wrote an email to you about my linux based IGMPv3 
implementation where I  have implemented setsockopt() and getsockopt() as the 
API for storing and  retrieving multicast source filter information for full-
state API applications. Since I had my kernel patch and userAPI examples as 
file attachments in that email I am not sure if the email may have been 
filtered out.

    In your multicast source filter API draft <draft-ietf-magma-msf-api-
03.txt>, the guidelines for full-state API suggested use of ioctls as it said 
getsockopt could not be used to retrieve multicast filter information. I have 
implemented full-state API using setsockopt & getsockopt. For my latest patch 
implementing all the API's as per current draft as well as my rather 
proprietary structs for getsockopt & setsockopt implementation, please visit: 
http://home.attbi.com/~v.kulkarni/igmpv3/igmpv3.html

    After exchanging a few emails with Linux kernel maintainters for network 
code, I realised that they too preferred getsockopt & setsockopt for full-
state API over ioctls. While it's just a tiny matter about implementation I & 
a few maintainers on the linux community feel that the API uniformity achieved 
by doing so may be desirable. As authors of the draft, we would like to have 
your approval in this regard.

While I am currrrently working on using standard struct ip_msfilter with 
set/getsockopt and cleaning out some of the gore from the above implementaion, 
I breifly describe a proposal for using getsockopt for full-state API.

SETSOCKOPT:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Toerless Eckert | 12 Jan 2003 23:28
Picon
Favicon

Re: Re: getsockopt for full-state source filter API

It would of course be nice to have this reasoning at least in an
appendix of the MSFAPI draft so that future generations are still
aware of the reason for the compromises taken - helps especially those
folks who in a couple of years want to revise the decisions.

Cheers
	Toerless

On Sun, Jan 12, 2003 at 02:07:45PM -0800, Bill Fenner wrote:
> 
> >    After exchanging a few emails with Linux kernel maintainters for network
> >code, I realised that they too preferred getsockopt & setsockopt for full-
> >state API over ioctls.
> 
> This is a Linux implementation detail.  The implementation of getsockopt()
> in BSD 4.4 and earlier did not pass the user data to the protocol layer,
> so the only information the protocol layer can be guaranteed to have
> is the optname (e.g. IP_ADD_MEMBERSHIP).  Thus, a portable API cannot
> assume that the data in the buffer the user passed to getsockopt() is
> available to the protocol.
> 
> We considered using setsockopt() for setting the full-state, and ioctl()
> for retrieving the full-state, but decided that it would be better to
> have a consistent set/get API.  Since getsockopt()'s limitations required
> us to use ioctl() for get, we use ioctl() for set too.
> 
>   Bill
> _______________________________________________
> magma mailing list
> magma <at> ietf.org
(Continue reading)

Permalink | Reply | 0 comments |

Gmane