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

[<[e-mail]>]

Dear Carsten,

Please see inline. 

Cheers,
Med 

>-----Message d'origine-----
>De : Carsten Bormann [mailto:[e-mail]] 
>Envoyé : mercredi 9 mai 2012 20:21
>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>Cc : 
>[e-mail]
>g; [e-mail] application-layer protocols; The 
>IESG; [e-mail]; [e-mail]
>Objet : Re: APPSDIR review of 
>draft-ietf-mboned-64-multicast-address-format-01
>
>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.

Med: Ok. I'm planning to do these changes:

(a) Re-insert this appendix: http://tools.ietf.org/html/draft-boucadair-behave-64-multicast-address-format-03#appendix-A.2 and a reference to it in the introduction?

(b) Add this text to the introduction:

   Recently various solutions (e.g., [I-D.venaas-behave-v4v6mc-framework],
   [I-D.ietf-softwire-mesh-multicast] or [I-D.ietf-softwire-dslite-multicast]) have been proposed to allow
   access to IPv4 multicast content from hosts attached to IPv6-enabled
   domains.

   Even if these solutions have distinct applicability scopes
   (translation vs. encapsulation) and target different use cases, they
   all make use of specific IPv6 multicast addresses to embed an IPv4
   multicast address.  Particularly, the IPv4-embedded IPv6 multicast
   address is used as a destination IPv6 address of multicast flows
   received from an IPv4-enabled domain and injected by the IPv4-IPv6
   Interconnection Function into an IPv6-enabled domain.  It is also
   used to build an IPv6 multicast state (*, G6) or (S6, G6)
   corresponding to their (*, G4) or (S4, G4) IPv4 counter parts by the
   IPv4-IPv6 Interconnection Function.

Are you OK with these proposed changes?

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

Med: The problem statement document has been adopted as an mboned WG document. I added this sentence:

   More discussion about issues related to IPv4/IPv6 multicast can be
   found at [I-D.jaclee-behave-v4v6-mcast-ps].


>
>>> ** 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)?

Med: What do you think is needed to be added to http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-01#section-6? Thanks.

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

Med: The provisioning mechanism (e.g., dhcp, netconf, etc.) is not "aware" of the semantic. There are no specific requirements compared to another provisioning context. If your comment is related to http://tools.ietf.org/html/rfc6052#section-5.2, this is already captured in the Security Considerations section.

>I think the format just needs to state those.
>Pointing to a protocol as an existence proof would also be an 
>improvement.

Med: I added a I-D.ietf-softwire-multicast-prefix-option as an informative reference.

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

Med: The current text says that up to 2 MPREFIX64 can be provisioned; one prefix for ASM and another one for SSM. Just like any other configurable parameter, the value of these parameters will be set to the latest (valid) enforced configuration. I still don't see what I can add to Section 6. 
 

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

Med: Thanks. I updated the text.

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

Med: The entity managing the IPv4/IPv6 Interconnection function.

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

Med: Yes, but still this is a generic issue for RFC6052. Some deployment-specific documents already covered this point: e.g., http://tools.ietf.org/html/draft-ietf-softwire-dslite-multicast-02#section-5: 

"The mAFTR and mB4 MUST use the
   same mPrefix64 and uPrefix64, as well as run the same algorithm for 
   building IPv4-embedded IPv6 addresses."

Do you want to see a similar wording in the address format draft?