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

[Carsten Bormann <[e-mail]>]

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?

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

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

>  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