Re: [MBONED] APPSDIR review of draft-ietf-mboned-64-multicast-address-format-01

[Tina TSOU <[e-mail]>]

Sent from my iPad

On May 9, 2012, at 11:54 AM, "Carsten Bormann" <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mboned