Hi Stig,
Sorry I missed the discussion, and your comments, inline please, hope it
won't be too late.
On 6/8/2012 Friday 1:43 AM, Stig Venaas wrote:
Here are my last call comments. I think substantial changes are
needed to the draft.
I understand that this draft is focusing on dslite. But it appears that
it is a generic solution. As it says in the draft:
An IPv4 receiver accesses IPv4 multicast contents over an IPv6-
only multicast-enabled network.
Based on this, I think the scope of the draft, the title and
introduction etc should be updated to actually show that it is
a generic approach. And then instead list dslite as one of the
scenarios where this is needed.
Since it is a generic approach, I think it should also be reviewed,
perhaps an additional WGLC, in mboned. pim wg may also have some
interest in reviewing it. There are some errors regarding pim in
this document.
In particular, it discussed translation of IGMP/MLD. This is a
topic that has been discussed in mboned/pim, and there is also
another draft discussing this.
It refers to draft-ietf-mboned-64-multicast-address-format-01. If that
is to stay, I think this draft needs to wait to see what happens with
the address-format draft in 6man. Changes may be needed in this draft
depending on what happens. If only minor changes, the examples in this
draft may need to be updated.
Thanks, it's true. We'll wait for the comments from 6man, and update it
accordingly if needed.
Technical issue:
In 4.2 it says:
The mB4 uses the G6 (and both S6 and G6 in SSM) to create the
corresponding MLD Report message. The mB4 sends the Report message
to the MLD Querier in the IPv6 network. The MLD Querier (typically
acts as the PIMv6 Designated Router) receives the MLD Report message
and sends the PIMv6 Join to join the IPv6 multicast distribution
tree. The MLD Querier can send either PIMv6 Join (*,G6) in ASM or
PIMv6 Join (S6,G6) in SSM to the mAFTR.
As is noted, the MLD querier and the DR may be different routers.
It is the DR and not the MLD Querier (if they are different) that
sends the PIM join. Also note that they are often different. If
there are two routers, then the one with the lowest address is the
MLD querier, while the one with the highest address (unless DR
priority is configured) is the DR.
I understand your concern. I guess the Proxying spec solved this issue.
Near the end of 4.2:
A branch of the multicast distribution tree is then grafted,
comprising both an IPv4 part (from the mAFTR upstream) and an IPv6
part (from mAFTR downstream to the mB4).
It says "is then grafted". So it sounds like the branch is added
to the tree after the procedure has finished. But basically it is
being added to the tree bit by bit as the joins are sent hop by
hop. Maybe it could say "is in this way grafted" or something.
I'm also a bit unsure whether "grafted" is a good term, as "graft"
has a specific meaning for PIM Dense Mode.
Thanks for your suggestion, we'll reword it, and make it clarified.
At the end of 4.2:
The mAFTR MUST advertise the route of uPrefix64 with an IPv6 IGP, so
as to represent the IPv4-embedded IPv6 source in the IPv6 multicast
network.
Yes, probably in the IGP. Perhaps say more explicitly that there must
be a route due to PIM's use of RPF. I see this is mentioned in 7.1
though.
Ok.
In 6.1 it talks about IGMP messages being translated to MLD. I would
argue that this is not necessarily how this would be done.
Right, I agree with you. Please see my response to Simon, we can update
the text to clarify that.
If you look at a pure MLD proxy, you build state for various (*,G)
or (S,G) based on the reports you receive. Then based on this state
you create reports that you send upstream. It is not the message
from downstream that is just sent upstream. In this case, when
receiving downstream IGMP reports, they could be used to create the
IPv6 state. And then independent of whether the state was created
due to IGMP or MLD reports, reports are sent upstream, created from
that state. If you do this, messages are not translated.
In 7.1 it says:
information to discover the source. In order to pass the Reverse
Path Forwarding (RPF) check, the IPv6 routers MUST enable PIM on the
interfaces which has the shortest path to the uPrefix64.
Note that the shortest path might change due to topology changes, links
going down or coming up etc. So one would typically enable PIM on all
the routers. If one wants to constrain multicast to only some of the
topology, there are ways to build a separate multicast RIB for those
routers, and then enable PIM on all of them.
The text just focuses on the special configuration, I understand your
concern that it's a little confusing.
Maybe we can add some text like "... as prerequisites, basic multicast
related configurations should be done accordingly ..."
In 7.2 it says something about (*,G6) in mRIB6. The multicast RIB
is something different. I think it should say TIB. Check the terms
MRIB and TIB in RFC 4601.
I'll check the terms again.
The draft assumes PIM-SM is used. I think the approach could also
be used with e.g. PIM Bidir (RFC 5015).
Ok, we'll discuss this and come back to you on this point.
7.5 talks about scope, and mentions E and 8. Then it says that
this specification does not specify which scope to use. I would
perhaps not mention E and 8 then, it seems now to indicate that
those are the only alternatives.
Fine.
The security considerations should probably be extended a bit.
E.g. what about scoping? Can one traverse a scoped boundary by
say joining a v4 scoped group using a join for a global v6
prefix?
Ok, we'll consider that.
The draft should point out that it is just plain IPv4 in IPv6. At
least that seems to be the intention. However, one might use the
same solution with other tunnel types, e.g. GRE.
We have a similar intention as the DS-Lite spec., we can some text.
Minor nits:
Thanks, done.
o PIMv4: refers to PIM when deployed in an IPv4 infrastructure
(i.e., IPv4 transfer capabilities are used to exchange PIM
messages).
o PIMv6: refers to PIM when deployed in an IPv6 infrastructure
(i.e., IPv6 transfer capabilities are used to exchange PIM
messages).
Replace transfer with transport?
Section 6.4 starts with this:
If the mB4 function is implemented in the host which is directly
connected to an IPv6-only network. If an IPv4 application running in
I'm not exactly sure what the first "if" refers to. This needs to be
reformulated.
Also in 6.4 there is this typo: "implemntation".
Stig
Thanks again for your careful review and comments.
Cheers,
Jacni
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
