Subject: [magma] draft-ietf-magma-msf-api comments

From: Toerless Eckert <[email-masked]>
Date: Tue, 23 Sep 2003 10:40:24 -0700

One suggestion for draft-ietf-magma-msf-api-<next>:

Section 8.2 defines a protocol independent API, which i think is
going forward the recommended API, at least as long as dual stack v4/v6
is the most likely candidate for software (not necessarily deployments),
eg: write software independent of IPv4 and IPv6 as much as possible.

 a) To make the code of IP multicast application much closer to address
    family transparent (at least IPv4/IPv6), we should add IPv4/IPv6
    independent setsockopt()/getsockopt() parameters to superceede:

    IP_MULTICAST_IF   IPV6_MULTICAST_IF
    IP_MULTICAST_TTL  IPV6_MULTICAST_HOPS
    IP_MULTICAST_LOOP IPV6_MULTICAST_LOOP

    I would propose to define in the MSFAPI:

    IP2_MULTICAST_IF
    IP2_MULTICAST_HOPS
    IP2_MULTICAST_LOOP

    (although i do not really care for the names, just that they are
     available).

    (and yes, thoretically the setsourcefilter/getsourcefilter are
     usable for other address families than IPv4/IPv6 whereas the above
     proposed API calls are limited to IPv4/IPv6, but i think that's no
     strong argument not to add them.)

    A bit more borderline but in the same boat are:

      IP2_DEFAULT_MULTICAST_TTL  1
      IP2_DEFAULT_MULTICAST_LOOP 1
    
    as well as a definition that a default multicast interface is to
    be supported and so on - if we agree to go this way i could provide
    some more detail.

    Why is this important ? Well, correct me if i am wrong, but i
    can not find a single normative reference (IEEE, open group or ISOC)
    that specifies the IPv4 multicast API. More specifically, reference
    [2] from the MSFAPI draft does _NOT_ specify the IPv4 multicast API
    functions like IP_ADD_MEMBERSHIP, IP_DROP_MEMBERSHIP, so it is a
    miracle that operating systems actually do provide IP multicast API
    support - guess they all copy from BSD code and not POSIX code ;-)

    Anyhow: instead of trying to specify this legacy API, i think we
    should rather go forward and specify all the elements needed to provide
    a complete IPv4/IPv6 address family transparent API - and it's really
    not all that much work, right ?
    
    If you consider this NOT to be the focus of the current MSFAPI spec,
    then i would like to point out that the MSFAPI should have some normative
    reference towards all the IPv4 inherited API calls mentioned in
    4.1.1., and as said above i think you would have trouble finding
    such normative reference. If on the other hand we declare this IPv4 only
    API to be superceeded by an IPv4/IPv6 one, then this would at least
    in my opinion release the pressure on that argument...

    I at least would like to see a complete and usable API for IPv6 AND
    IPv4 multicast to pop up at the POSIX side of things, and given that
    those folks only seem to copy randomn elements from RFCs, the only
    good starting point seems to be writing these things down into an
    RFC, right ? So why not this one ;-))

 b) 5.2.2 incorrectly states that the interface argument holds the
    IP address of the interface, instead it holds the interface index.
    
    I would suggest to change the name of the parameter from "interface"
    to "if_index" in both setsourcefilter() and getsourcefilter().

    It would also good to note appropriately that the values for if_index
    are those used with RFC3493, section 4.1/4.2 (just normal paranoia...;-)
 
 c) How about defining that source lists of at least 10 elements MUST
    be supported ?

Thanks
	Toerless

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