Subject: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04

From: Tina TSOU <[email-masked]>
Date: Tue, 23 Aug 2011 01:58:14 +0000

Hi all,
In IETF-81, the chairs asked the authors of different drafts on multicast sit together to discuss and compromise. So we did.

Here are some comments on draft-qin-softwire-dslite-multicast-04.

Overall: if this is to be a Standards Track document, the whole document 
has to be reviewed, the normative parts identified, and requirements 
language substituted for the current descriptive language.

Section 1:

Editorial: at the end of the second paragraph, "vastly consumed" reads 
better in English as: "consumed in vast quantities".

Substantive: add the following to the sentence making up the third 
paragraph:

"..., which prevents these consequences by making use of the native 
multicast capabilities of the intervening IPv6 network."

Section 2:

Terminology: "Multicast AFTR" has connotations (IPv4 NAT) that simply 
aren't there. Suggestion: "Multicast Transitional Border Gateway (mTBG)".

Substantive(?): In the description of the Multicast B4, it would make 
more sense to change "... which is able to enforce ..." to "... which 
implements ...".

Section 3.2:

Bullet 1: the second sentence jams two unrelated ideas together. It 
needs a little expansion to read properly. The next sentence doesn't 
make sense within the stated scope of the bullet and shouldn't be there. 
The suggested changed text is thus:

   "A viable scenario for this use case in DS-Lite environment: customers
    with legacy receivers must continue to access the IPv4-enabled
    multicast services.  This means the traffic should be accessed
    through IPv4 and additional functions are needed to traverse the
    operator's IPv6- enabled network. It is the purpose of this
    document to describe those functions.  Refer to [I-D.jaclee-behave-
    v4v6-mcast-ps] for the deployment considerations."

Final paragraph: don't you need a final sentence saying something like: 
"Depending on the specific details of the contract, this may mean that 
the specific framing of the content packets (as IPv4 packets) must be 
preserved along with the content within that framing."

Section 4:

First paragraph: the following sentences need to be added after the 
first one to give a full picture of what is required for a solution:

"For multicast, in contrast, separate mechanisms are required to process 
the outgoing multicast signalling packets and the incoming packets of 
content. The multicast signalling needs to be interworked to IPv6 and 
processed as IPv6 signalling. For incoming multicast content, this 
document defines ..."

Middle paragraph: why doesn't it simply read:

"See Section 4.3 for multicast distribution tree establishment and 
Section 4.4 for multicast traffic forwarding."

Section 4.2

Third paragraph typo: mPrefixe64 -> mPrefix64

Section 4.3

Bullets: it makes no sense to embed the mAFTR in the MLD Querier. That 
would cause the native IPv6 multicast infrastructure to be bypassed. It 
is also inconsistent with the architectural figure. Delete the first 
bullet and merge the second one with the next paragraph, like this:

"The mAFTR should process the received PIMv6 Join message for the 
IPv4-embedded IPv6 group and send the corresponding IPv4 PIM Join 
message. It creates an entry for the IPv6 multicast group address in its 
multicast Routing Information Base. This entry is used to forward ..."

Section 4.5

It is not clear whether the final paragraph is talking about the mB4+B4 
or the mAFTR+AFTR or both. In fact, it makes good sense to combine the 
mB4 and the B4, but combining the AFTR and mAFTR would be questionable 
for reasons of scalability. There may be routing issues to sort out 
regarding reachability of the IPv4 prefix that is shared by the source 
-- the multicast routers should choose the path leading through the 
mAFTR rather than the one going through the AFTR.

No more comments up to section 7. Maybe more comments from section 7 
onwards in a separate E-mail.

Regards,
Tina

---

From: Jacni Qin <[email-masked]>
Date: Tue, 23 Aug 2011 22:32:19 +0800

Thanks for the comments, inline please.

On Tue, Aug 23, 2011 at 9:58 AM, Tina TSOU <[email-masked]>wrote:

> Hi all,
> In IETF-81, the chairs asked the authors of different drafts on multicast
> sit together to discuss and compromise. So we did.
>
Jacni>: I don't see it, while you can post comments.

Section 1:
> Jacni>: Sorry, EN is not my first language. Maybe we need the help
from a native guy.

> Jacni>: No objection to add a sentence, but modified as "which preserves
the efficiency of using multicast for traffics forwarding."

> Jacni>: I think the AFTR is a general item, see the similar comments raised
in another thread about 4rd.

> Jacni>: Sorry, I don't agree. I think text in the paragraph following the
bullet
explains the scope clearly.

> Jacni>:That's what the current text means.

> processed as IPv6 signalling. For incoming multicast content, this

Jacni>: The signalling things will be detailed in the signalling section.
This is just a general description here.

> Third paragraph typo: mPrefixe64 -> mPrefix64
Jacni>: Oops, got it, thank you.

> bullet and merge the second one with the next paragraph, like this:
Jacni>: Actually, this is one of the typical cases.
The mAFTR can be embedded in the MLD Querier, which will
not bapass the IPv6 multicast infrastructure.

> for reasons of scalability.

Jacni>: We don't see the problems so far.

> There may be routing issues to sort out

Jacni>: Sorry, I don't understand the ".. IPv4 prefix that is shared by the
source.."
For multicast routing, multicast routers including mAFTR will deal with that
based on
converged unicast routing.
You can learn more about it in the following sections.

> onwards in a separate E-mail.
Jacni>: Thank again for your comments.

Cheers,
Jacni

>
> Regards,
> Tina
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 23 Aug 2011 23:54:37 +0000

Hi Tina,

Thanks for the review. Comments below:

>    v4v6-mcast-ps] for the deployment considerations."

[YL] I don't follow your argument saying "jams two unrelated ideas
together". What we tried to say was an operator could use dual-stack.
However, I would agree we should remove to discuss the dual-stack case
because this is targeted for DS-lite.

>preserved along with the content within that framing."

[YL] We spoke the same thing. We can clarify in next revision.

>processed as IPv6 signalling. For incoming multicast content, this

[YL] We will consider this. I would suggest to the following instead:

"In the original DS-lite specification, an IPv4-in-IPv6 softwire is used
to carry the bidirectional IPv4 unicast traffic between B4 and AFTR. This
document defines an IPv4-in-IPv6 encapsulation scheme to deliver
unidirectional multicast traffic from IPv4 multicast source behind AFTR to
the IPv4 multicast receiver behind B4. This specification defines to
interwork IPv4 multicast and IPv6 multicast protocols (e.g. IGMPv3 <->
MLDv2) and to deliver IPv4 multicast packets in IPv6 encapsulation."

>Third paragraph typo: mPrefixe64 -> mPrefix64

[YL] Fixed

>bullet and merge the second one with the next paragraph, like this
>

[YL] I don't follow this. How would mAFTR bypass native IPv6 multicast
infrastructure? This is another deployment scenario which would allow an
operator to deploy mAFTR in the CPE's default router. However, to
eliminate confusion, we could move this in a different section.

>mAFTR rather than the one going through the AFTR.

[YL] We were talking mAFTR and AFTR, and mB4 and B4. All we were saying
this was possible. We didn't enforce it. I would suggest to remove the
entire section since this is a deployment option, not so much about
specification.

Regards,
Yiu

---

From: <[email-masked]>
Date: Wed, 24 Aug 2011 08:43:35 +0200

Hi Tina,

Thank you very much for reviewing carefully this document.

Your editorial suggestions will be considered when we will generate the next revision of the I-D. 

As for the comment about the co-location of the MLD Querier and mAFTR, this is a deployment scenario among others. The I-D only discusses that case. Please keep in mind this I-D defines "functional elements" and not "nodes".

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Tina TSOU
Envoyé : mardi 23 août 2011 03:58
À : [email-masked]
Objet : [Softwires] Comments on draft-qin-softwire-dslite-multicast-04

Hi all,

Section 1:

Section 2:

Section 3.2:

Section 4:

Section 4.2

Section 4.3

Section 4.5

Regards,
Tina