Sent from my iPad
On May 9, 2012, at 11:54 AM, "Carsten Bormann" <[email protected]> wrote: > Hi Med, > > thanks for looking into my review. Let me take this opportunity to reiterate > that, while I wrote this review for the Applications Area Directorate, it is > not intended to bear more weight than any other comment submitted by an > individual during a Last Call. > >> Med: There are plenty of applications using this address format: e.g., >> [I-D.ietf-softwire-mesh-multicast], [I-D.ietf-softwire-dslite-multicast], >> [I-D.ietf-softwire-multicast-prefix-option], >> [I-D.venaas-behave-v4v6mc-framework], >> [I-D.sarikaya-behave-netext-nat64-pmip], >> [I-D.sarikaya-behave-mext-nat64-dsmip], etc. We had pointers to some of >> those drafts in earlier versions of the document but we removed them and >> adopted the same approach as RFC6052: only the address format is defined >> while the usage is defined in companion documents. > > The problem with this is that you now have a bit allocation without any > semantics. > What is different, then, from any other way to allocate multicast addresses? > If you want this part of the address space to have some specific semantics, > you have to give it some. > >> More details are also documented here: >> http://tools.ietf.org/html/draft-boucadair-behave-64-multicast-address-format-03#appendix-A.1 >> and >> http://tools.ietf.org/html/draft-boucadair-behave-64-multicast-address-format-03#appendix-A.2. >> >> >> There is also a problem statement, available at: >> http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-03 which can be >> cited in the introduction. > > I do believe that there needs to be some indication in the document. > Maybe some of the material from the problem statement can be put into an > appendix. > BTW, what is the plan with the problem statement document? Was this too > contentious to make it a WG document? It's has been adopted as MBONED WG item. The authors will submit the WG draft soon. > >>> ** Major Issues: >>> >>> To continue the summary: I don't understand which network elements >>> need to be able to determine, by looking at an IP address, that this >>> document is in use. What for? More generally, which entities need to >>> interoperate based on a common understanding of this format? >> >> Med: Elements which make use of the address format are deployment-specific; >> this can be a receiver, an IPv4-IPv6 PIM interworking function, IGMP/MLD >> Interworking function. We didn't quoted these interworking functions because >> this is deployment-specific. Do you think your issue can be solved if we add >> a pointer to one of the solutions documented listed above? > > So the idea is that this is a common format that can be used by any number of > transition mechanisms? > How do you avoid the mechanisms getting confused (e.g., one mechanism > allocating an address that is then processed incorrectly by a network element > that is using another mechanism)? > > Yes, I think standardizing this document in a cluster with one or more > transition mechanism documents and adding mutual references would be the best > way to handle this. As long as the question above has a good answer... http://datatracker.ietf.org/doc/draft-perreault-mboned-igmp-mld-translation/ http://datatracker.ietf.org/doc/draft-taylor-pim-v4v6-translation/ > >>> Of the various fields left "configurable according to local policies >>> of the entity managing the IPv4-IPv6 Interconnection Function", which >>> are important for applications? How do they know these policies? >> >> Med: The content of this filed is left configurable. Its value will depend >> on the policies enforced by the administrative entity. Examples of these >> policies are: embedded-RF, use unicast-based prefix, etc. Applications are >> not aware of these policies since a prefix will (likely /96) will be >> provisioned (see Section 6). >> >> If >>> that information is all in the two parameters "ASM_MPREFIX64" and >>> "SSM_MPREFIX64", what is the protocol that will be used to make this >>> information available to applications? I don't think this can be a >>> standards-track document without defining at least one MTI protocol >>> for disseminating this information. >> >> Med: The provisioning of the ASM_PREFIX64 and the SSM_PREFIX is orthogonal >> to the address format itself. Various methods can be used but this is out of >> scope of the document. We can add a pointer to >> http://tools.ietf.org/html/draft-ietf-softwire-multicast-prefix-option-00 as >> a provisioning example. Would you be fine with adding such reference? > > Are there any requirements on the provisioning mechanism to maintain the > integrity of the semantics you desire? > I think the format just needs to state those. > Pointing to a protocol as an existence proof would also be an improvement. Good suggestion. > >> What is an implementation >>> supposed to do that receives an address that looks like it is governed >>> by this document but does not conform to either of the agreed >>> prefixes disseminated to the implementation? >> >> Med: This is an issue for the provisioning method and not for the >> specification of the address format itself. > > I'm not sure about that. If I get a conflicting address using some control > protocol, should I deny that? Just go ahead anyway? > Will this confuse the network elements performing the transition mechanisms? > (My questions may sound very theoretic, but that is because the draft just > doesn't tell me enough to even know whether these are good questions.) > >> Med: Could you please suggest a better title? > > Well, given that RFC 6052 already uses "IPv4-embedded" in what I read as the > inverted semantics, this naming is hard to fix. > But maybe > > IPv6 Multicast Address Format With Embedded IPv4 Multicast Address > > is not too long and much less ambiguous. > >>> 3 >>> >>> The role of 64IX is very unclear. My conjecture is that this draft is >>> defining the address format for the case M=1 only (i.e., address[16] = >>> 1). No text defines what happens for M=0, so the assumption appears >>> to be that RFC 4291 applies unchanged in this case. If this >>> conjecture is correct, this needs to be made much clearer. >> >> Med: The current text says: "When "M-bit" is set to 1, it indicates that a >> multicast >> IPv4 address is embedded in the low-order 32 bits of the multicast >> IPv6 address.". I can add: "When "M-bit" is set to 0, the address format >> follows [RFC4291].". Would this be fine with you? > > Yes, maybe make even more explicit that this document just governs those > addresses where the M bit is set to 1. > >>> What is "r"? Define. >> >> Med: This means "reserved". The text says: "All the remaining bits are >> reserved and MUST be set >> to 0.". Do you think the text should be clarified further? > > Yes. I think you should not talk about a "64IX" nibble at all (which then > requires you to reserve three of those four bits) but just talk about the one > M bit that you are assigning semantics to. > >>> 4 >>> >>> Why is 64IX moving around here? >>> (The discriminating bit M now seems to be address[32].) >>> How does one find out which of the two positions of the M bit to use? >> >> Med: Once the prefix is configured to a receiver, an IPv4-IPv6 PIM >> interworking function, the question of the location of the M-bit is not >> relevant anymore. If both ASM and SSM modes are supported, two prefixes will >> be used. > > Again, that is true if all network elements agree on the provisioned prefixes. > But if they do, what is the point of this document? > Just saying "transition mechanisms can allocate a 96-bit prefix to which a > 32-bit IPv4 multicast address is appended" would be enough then, no? > > I get the idea that people want to write code that looks at this bit and > exhibits different behavior based on whether it is set or not. > If that is not the case, there is no need for that bit... > >>> . o sub-group-id: The default value is all zeros. >>> How does an application find out when to choose a different one? >> >> Med: Applications are provisioned with the full prefix; see Section 6. > > But what does "default value" mean then? Who is doing the defaulting, and > what does it mean to use the default or to not use it? > >>> . 232.0.0.1-232.0.0.255 range is being >>> . reserved to IANA. >>> Who is making this reservation? ("is being reserved" means the >>> resernation is going on right now, but I don't find anything in 9.) >> >> Med: We removed that sentence as a result of a comment I received from SM >> (see mboned archives). > > Fine. > >>> 7 >>> >>> 7 seems to imply this format is only useful where RFC 6052 is in use. >>> If this is true, this should be clearly stated. More specifically, >>> the assumption appears to be that all nodes that need to exchange >>> information that concerns IPv4 sources need to have the same RFC 6052 >>> parameters in effect. How is that ensured? >> >> Med: This is a generic issue for RFC6052. We can document the issue if it is >> specific to the multicast context. > > I actually think it is more interesting in the multicast case, because > multicast can span multiple domains (where a unicast address is assigned to > one node that is "in" a specific domain). > > Grüße, Carsten > > _______________________________________________ > MBONED mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/mboned -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
