Subject: mboned: Comments on draft-ietf-mboned-addrarch-00.txt

From: Jerome Durand <[email-masked]>
Date: Thu, 27 Jan 2005 12:14:55 +0100

Hi, some comments below (following the text order...) I tried to make 
similar exercise some time ago in
   - http://www.6net.org/publications/deliverables/D3.4.4.pdf
   - I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6
and it's good to put things again on the table...

2.1.2  Unicast-prefix -based Allocation
    A difference to RFC 3306 is, however, that the hosts
    cannot calculate their "multicast prefix" automatically, as the
    prefix depends on the decisions of the operator setting up the RP but
    rather needs to be communicated somehow

==> I would here say that assignment is needed.

3.1  Derived Assignment

==> For me this would be allocation. I agree this is not what you say in 
the intro but I think assignment somehow implies that "someone" tells 
you: "you can use that address or that set of address".

==> Also I have some other problems with ietf-ipv6-link-scoped-mcast but 
that is another story :)

3.3  Manually Configured Assignment

==> As this is "the most commonly used technique when the multicast 
application does not have a static IANA assignment" we should say a bit 
more I guess. Should we talk here about random address choice? Collision 
probability? How bad it is? Why is that okay today as few people use 
IPv4/v6 mcast? I don't know how many details we should give but maybe we 
should explain why this is "the most commonly used technique when the 
multicast application does not have a static IANA assignment" :)

3.4  Static IANA Assignment
    this is a bad approach architecturally, as we should focus on
    enhancing and deploying service discovery and address assignment (as
    needed) instead of encouraging a "land-grab" of multicast addresses.

==> Well I must admit that if procedures to get multicast addresses are 
well defined and that there are responsive teams ready to assign 
multicast addresses, I am not sure I get problems with this solution for 
assigning addresses to some well-defined apps, conference channels... 
that could then bu put in DNS.

3.5  Dynamic Assignments
[I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6]

==> I will publish an updated version next week. I will be able to link 
the complete part "5.  Review of existing assignment protocols" to this 
document that was really missing at the time we started. Useful, thanks!!!

==> I am a bit surprised that this section is so small. At least a 
section on MADCAP is essential.

    In consequence, more work on rendezvous/service discovery will be
    needed to make dynamic assignment more useful.

==> You can take the proble the other way around. At least for IPv6, if 
you assign embeddedRP addresses to the client, then you solve the 
rendezvous discovery problem :) Here we can insist a bit how much 
address assignment is important and can easily solve the complete 
problem. I tried to depict that in 
[I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6] but this doc I guess is 
the good place for that.

4.  Multicast Address Discovery

    [[ NOTE IN DRAFT: it is not clear whether this section belongs in
    this document at all; it is somewhat related, but could bear a more
    extensive discussion elsewhere.  It should likely go in a separate
    document (if there was one discussing these problems!), or in an
    appendix.  Feedback is appreciated.  ]]

==> I think you can't speak about address assignment/allocation without 
saying at least what clients will do with the address. So a short 
section is needed. BTW I am a bit surprise to see nothing on SAP?

5.2  Address Assignment

"Dynamic assignment, e.g., using MADCAP have been implemented, but there 
is no wide deployment, so a solution is there"

==> Only for IPv4 I suppose. If not used by apps and almost not 
available as there are very few immplementations, not sure we should say 
the solution is there. OK you can take the problem the other way around 
and say that there is no demand.

Thanks

Jerome
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Jerome Durand <[email-masked]>
Date: Thu, 27 Jan 2005 13:02:01 +0100

>   - http://www.6net.org/publications/deliverables/D3.4.4.pdf

Sorry, I meant http://www.6net.org/publications/deliverables/D3.4.3.pdf 
and that was IPv6 specific.

Jerome