Hi Carsten,
Thanks a lot for your comments, please see inline below.
On 5/10/2012 Thursday 2:20 AM, Carsten Bormann 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.
For the semantics, you can see YIu's point. More specifically, for
example, some adaptive/interworking function of network elements can
interpret it as, if the M bit is set 1, then pick the corresponding IPv4
group address.
** 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)?
Not sure whether I understand your question here correctly, but let me
try to,
The address/prefix allocating should be an independent component of the
service provisioning, and should just make a consistent assignment of
the block throughout the related elements. The format standardized is
for the elements to perform the adaptive function without any coordination.
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...
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.
I guess standardizing the format is to maintain the integrity of the
semantics. For the responsibility of address/prefix provisioning
mechanism, please see my response above.
Or maybe I misunderstand your question?
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?
It should be in the scope of operations or deployment, to avoid that.
(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.
We'll consider it, thanks a lot.
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?
In this way, the elements have to maintain "states", and coordination is
required. Even though, they also have to be told how to derive the IPv4
multicast address embedded.
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?
It can mean, for example "if RFC3956, embedding RP in an IPv6 multicast
address is not used".
Cheers,
Jacni
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
--------------------------------------------------------------------
