Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Hi Med, In line with [TT2]... Best Regards, Tina From: mohamed.boucad...@orange-ftgroup.com [mailto:mohamed.boucad...@orange-ftgroup.com] Sent: Thursday, August 25, 2011 12:06 AM To: Tina TSOU; Jacni Qin Cc: softwires@ietf.org Subject: RE: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi Tina, Please see inline. Cheers, Med De : Tina TSOU [mailto:tina.tsou.zout...@huawei.com] Envoyé : mercredi 24 août 2011 20:26 À : BOUCADAIR Mohamed OLNC/NAD/TIP; Jacni Qin Cc : softwires@ietf.org Objet : RE: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Bonjour Med, Ca va? Thank you for your deep insight and reply. When the IPv6 packet comes, how does mB4 know it should make encapsulation or translation if mPrefix64 and uPrefix64 are the same? As defined in section 6.3 of draft-boucadair-behave-64-multicast-address-formathttp://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04#ref-I-D.boucadair-behave-64-multicast-address-format, there is no need to reserve a bit in the IPv6 multicast address to separate between the translation and the encapsulation schemes. So when mPrefix64 and uPrefix64 are the same for both encapsulation and translation, mB4 could not make decision which operation to make. In this case, the IPv6 header itself can be used to identify encapsulation or translation. For example, if the next header of IPv6 header is 4, mB4 should make de-capsulation because there is IPv4 packet inside. If it is other value, translation may be needed. [Med] Using the same mPrefix64 for both encap and translation is not recommended in draft-boucadair-* as you can read in the following excerpt: IPv4-IPv6 encapsulator and translator may be embedded in the same device or even implemented with the same software module. In order to help the function whether an encapsulated IPv6 multicast packets or translated IPv6 ones are to be transferred. It was tempting to define an S-bit for that purpose but this choice has been abandoned in favor of the recommendation to use distinct MPREFIX64 for each scheme. I don't see an issue here. [TT2] Since encapsulation and translation use different mPrefix64, it is not an issue in draft-qin-* now. But draft-boucadair-* does not specify how to make mPrefix64 different for encapsulation and translation. Do you think it is needed? From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange-ftgroup.com Sent: Tuesday, August 23, 2011 11:54 PM To: Tina TSOU; Jacni Qin Cc: softwires@ietf.org Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi Tina, Please see inline. Cheers, Med De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Tina TSOU Envoyé : mercredi 24 août 2011 04:21 À : Jacni Qin Cc : softwires@ietf.org Objet : Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi Jacni, Thank you for your early reply. Have a good day. My replies are below. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: Jacni Qin [mailto:jac...@gmail.com] Sent: Tuesday, August 23, 2011 6:09 PM To: Tina TSOU Cc: softwires@ietf.org Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 hi, On Wed, Aug 24, 2011 at 8:02 AM, Tina TSOU tina.tsou.zout...@huawei.commailto:tina.tsou.zout...@huawei.com wrote: Hi all, Some more comments on draft-qin-softwire-dslite-multicast-04. #1 General comment: is there any consideration of interaction with unicast solutions, e.g., potential collocation or reuse of functions? Do we need some mapping or interaction table of the function elements or tunnels (IP-in-IP or IP-in-non-IP) to show the relationship with DS-Lite unicast solution? Jacni: As Yiu mentioned in another email, the co-location with unicast DS-Lite elements is more deployment specific, and I'm ok to remove the section 4.5. From the protocol perspective, I don't see there is necessary interaction with the unicast solution. [TT] Section 4.5 is good for the readers to understand the difference between unicast and multicast DS-Lite. I strongly suggest add some texts into this section like the co-location of multicast elements with unicast DS-Lite elements is more deployment specific. [Med] OK. We will do. #2 Section 6.2 Translation and encapsulation both uses the same mPrefix64 and uPrefix64, so mB4 could not determine whether to de-capsulate the packets only based on mPrefix64 and uPrefix64. Propose to change as it checks whether the group address is in the range of mPrefix64, the source address is in the range of uPrefix64 and whether the next header of IPv6 header is 4. Jacni:Currently, we only employ the encapsulation for date forwarding in the main text. [TT] I am not talking about translation solution in the main text. Even if in the encapsulation case, mB4 needs to determine whether to make de
Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Hi Tina, Please see inline. Cheers Med De : Tina TSOU [mailto:tina.tsou.zout...@huawei.com] Envoyé : vendredi 26 août 2011 04:35 À : BOUCADAIR Mohamed OLNC/NAD/TIP; Jacni Qin Cc : softwires@ietf.org Objet : RE: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi Med, In line with [TT2]. Best Regards, [SNIP] [Med] Using the same mPrefix64 for both encap and translation is not recommended in draft-boucadair-* as you can read in the following excerpt: IPv4-IPv6 encapsulator and translator may be embedded in the same device or even implemented with the same software module. In order to help the function whether an encapsulated IPv6 multicast packets or translated IPv6 ones are to be transferred. It was tempting to define an S-bit for that purpose but this choice has been abandoned in favor of the recommendation to use distinct MPREFIX64 for each scheme. I don't see an issue here. [TT2] Since encapsulation and translation use different mPrefix64, it is not an issue in draft-qin-* now. But draft-boucadair-* does not specify how to make mPrefix64 different for encapsulation and translation. Do you think it is needed? Med: I confirm this is not an issue for draft-qin. In draft-boucadair, we can for sure clarify more and state the operator of the v4/v6 multicast intercinnection nodes configures two distinct mPREFIX64, ... ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Re-, L2-relatd considerations described in Section 8 of draft-qin does not require any specific behaviour from the mAFTR. I suggest we continue this thread off-line. Cheers, Med -Message d'origine- De : Tina TSOU [mailto:tina.tsou.zout...@huawei.com] Envoyé : vendredi 26 août 2011 04:31 À : BOUCADAIR Mohamed OLNC/NAD/TIP; Lee, Yiu; softwires@ietf.org Objet : RE: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Bonjour Med, Thank you for your comments. What Yiu said is not reflected in figure 3. In the current figure, mAFTR can receive (PIMv6 Join, PIMv6 Routers in between). However, if the IPv6 network is layer 2 network, mAFTR should be able to receive MLD report as well. mAFTR also performs MLD/PIMv4 interworking in this case. So I propose update figure 3 to be complete. Section 8 does not mention how mAFTR acts in this case. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange-ftgroup.com Sent: Thursday, August 25, 2011 1:11 AM To: Lee, Yiu; softwires@ietf.org Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi Tina, I agree with Yiu. FYI, we had a discussion between co-authors of the draft whether we maintain http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04#section-8 or remove it. You can read in that section: Additionally, mechanisms such as MLD Snooping, MLD Proxying, etc., can be introduced into the distributed Access Network Nodes (e.g., Aggregation Switches, xPON devices) which then could behave as MLD Querier and replicate multicast flows as appropriate. Thus, the multicast replication point is moved downward closer to the receivers, so that bandwidth consumption is optimized. What do you think is missing in that text? Cheers, Med De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Lee, Yiu Envoyé : jeudi 25 août 2011 05:31 À : softwires@ietf.org Objet : Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi Tina, What do you see new here in this scenario? mAFTR is a logical function, it would perform MLD PIMv4-Join interworking. This has been captured. If a vendor wants to make mAFTR also a L2 device, it would perform standard MLD snooping. What else is missing? Thanks, Yiu From: Tina TSOU tina.tsou.zout...@huawei.com Date: Thu, 25 Aug 2011 02:11:18 + To: softwires@ietf.org softwires@ietf.org Subject: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi all, One more comment on Section 7.4.2. This document only covers IGMP-MLD and PIMv6-PIMv4 scenarios. We also need to consider the scenario where it is layer 2 network between mAFTR and mB4. The architecture is as below: ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Hi Tina, I agree with Yiu. FYI, we had a discussion between co-authors of the draft whether we maintain http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04#section-8 or remove it. You can read in that section: Additionally, mechanisms such as MLD Snooping, MLD Proxying, etc., can be introduced into the distributed Access Network Nodes (e.g., Aggregation Switches, xPON devices) which then could behave as MLD Querier and replicate multicast flows as appropriate. Thus, the multicast replication point is moved downward closer to the receivers, so that bandwidth consumption is optimized. What do you think is missing in that text? Cheers, Med De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Lee, Yiu Envoyé : jeudi 25 août 2011 05:31 À : softwires@ietf.org Objet : Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi Tina, What do you see new here in this scenario? mAFTR is a logical function, it would perform MLD PIMv4-Join interworking. This has been captured. If a vendor wants to make mAFTR also a L2 device, it would perform standard MLD snooping. What else is missing? Thanks, Yiu From: Tina TSOU tina.tsou.zout...@huawei.commailto:tina.tsou.zout...@huawei.com Date: Thu, 25 Aug 2011 02:11:18 + To: softwires@ietf.orgmailto:softwires@ietf.org softwires@ietf.orgmailto:softwires@ietf.org Subject: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi all, One more comment on Section 7.4.2. This document only covers IGMP-MLD and PIMv6-PIMv4 scenarios. We also need to consider the scenario where it is layer 2 network between mAFTR and mB4. The architecture is as below: / \ | IPv4 network | \/ : | ^ IPv4 Multicast : | : PIMv4 Join v | : +-+ |mAFTR | +-+ |:| | ^ IPv6 Multicast |:| | : (MLD Report) (IPv4 embedded) |.| ... . +---+ | MLD proxy/| | snooping | +---+ |:| | : MLD Report |v| | : +---+ | mB4| +---+ : | ^ IPv4 Multicast : | : IGMP Report v | : +---+ | IPv4 | | Receiver | +---+ B. R. Tina ___ Softwires mailing list Softwires@ietf.orgmailto:Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Hi Tina, I agree with Yiu. FYI, we had a discussion between co-authors of the draft whether we maintain http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04#section-8 or remove it. You can read in that section: Additionally, mechanisms such as MLD Snooping, MLD Proxying, etc., can be introduced into the distributed Access Network Nodes (e.g., Aggregation Switches, xPON devices) which then could behave as MLD Querier and replicate multicast flows as appropriate. Thus, the multicast replication point is moved downward closer to the receivers, so that bandwidth consumption is optimized. What do you think is missing in that text? Cheers, Med De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Lee, Yiu Envoyé : jeudi 25 août 2011 05:31 À : softwires@ietf.org Objet : Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi Tina, What do you see new here in this scenario? mAFTR is a logical function, it would perform MLD PIMv4-Join interworking. This has been captured. If a vendor wants to make mAFTR also a L2 device, it would perform standard MLD snooping. What else is missing? Thanks, Yiu From: Tina TSOU tina.tsou.zout...@huawei.com Date: Thu, 25 Aug 2011 02:11:18 + To: softwires@ietf.org softwires@ietf.org Subject: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi all, One more comment on Section 7.4.2. This document only covers IGMP-MLD and PIMv6-PIMv4 scenarios. We also need to consider the scenario where it is layer 2 network between mAFTR and mB4. The architecture is as below: ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Bonjour Med, Thank you for your comments. What Yiu said is not reflected in figure 3. In the current figure, mAFTR can receive (PIMv6 Join, PIMv6 Routers in between). However, if the IPv6 network is layer 2 network, mAFTR should be able to receive MLD report as well. mAFTR also performs MLD/PIMv4 interworking in this case. So I propose update figure 3 to be complete. Section 8 does not mention how mAFTR acts in this case. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange-ftgroup.com Sent: Thursday, August 25, 2011 1:11 AM To: Lee, Yiu; softwires@ietf.org Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi Tina, I agree with Yiu. FYI, we had a discussion between co-authors of the draft whether we maintain http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04#section-8 or remove it. You can read in that section: Additionally, mechanisms such as MLD Snooping, MLD Proxying, etc., can be introduced into the distributed Access Network Nodes (e.g., Aggregation Switches, xPON devices) which then could behave as MLD Querier and replicate multicast flows as appropriate. Thus, the multicast replication point is moved downward closer to the receivers, so that bandwidth consumption is optimized. What do you think is missing in that text? Cheers, Med De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Lee, Yiu Envoyé : jeudi 25 août 2011 05:31 À : softwires@ietf.org Objet : Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi Tina, What do you see new here in this scenario? mAFTR is a logical function, it would perform MLD PIMv4-Join interworking. This has been captured. If a vendor wants to make mAFTR also a L2 device, it would perform standard MLD snooping. What else is missing? Thanks, Yiu From: Tina TSOU tina.tsou.zout...@huawei.com Date: Thu, 25 Aug 2011 02:11:18 + To: softwires@ietf.org softwires@ietf.org Subject: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi all, One more comment on Section 7.4.2. This document only covers IGMP-MLD and PIMv6-PIMv4 scenarios. We also need to consider the scenario where it is layer 2 network between mAFTR and mB4. The architecture is as below: ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
hi, On Fri, Aug 26, 2011 at 10:31 AM, Tina TSOU tina.tsou.zout...@huawei.comwrote: Bonjour Med, Thank you for your comments. What Yiu said is not reflected in figure 3. In the current figure, mAFTR can receive (PIMv6 Join, PIMv6 Routers in between). However, if the IPv6 network is layer 2 network, mAFTR should be able to receive MLD report as well. mAFTR also performs MLD/PIMv4 interworking in this case. So I propose update figure 3 to be complete. Section 8 does not mention how mAFTR acts in this case. Jacni: Figure 3 illustrates the functional elements, not layer 2 multicast things, while the IPv6 Network in the figure can be layer 2 if you want to understand it that way, no problem. What you said concerning two different things, * The layer 2 multicast mechanisms, like MLD Snooping, this approach is totally compatible with it. That's what Section 8 is talking about. Please see Yiu and Med's comments. * The MLD/PIMv4 is one of the scenarios, as we explained in previous emails. Also in the figure3, if there are PIMv6 Routers in between, the AFTR will receive PIMv6 join then do PIMv6/PIMv4, otherwise it will receive MLD messages then do MLD/PIMv4. Cheers, Jacni Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange-ftgroup.com Sent: Thursday, August 25, 2011 1:11 AM To: Lee, Yiu; softwires@ietf.org Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi Tina, I agree with Yiu. FYI, we had a discussion between co-authors of the draft whether we maintain http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04#section-8or remove it. You can read in that section: Additionally, mechanisms such as MLD Snooping, MLD Proxying, etc., can be introduced into the distributed Access Network Nodes (e.g., Aggregation Switches, xPON devices) which then could behave as MLD Querier and replicate multicast flows as appropriate. Thus, the multicast replication point is moved downward closer to the receivers, so that bandwidth consumption is optimized. What do you think is missing in that text? Cheers, Med De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Lee, Yiu Envoyé : jeudi 25 août 2011 05:31 À : softwires@ietf.org Objet : Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi Tina, What do you see new here in this scenario? mAFTR is a logical function, it would perform MLD PIMv4-Join interworking. This has been captured. If a vendor wants to make mAFTR also a L2 device, it would perform standard MLD snooping. What else is missing? Thanks, Yiu From: Tina TSOU tina.tsou.zout...@huawei.com Date: Thu, 25 Aug 2011 02:11:18 + To: softwires@ietf.org softwires@ietf.org Subject: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi all, One more comment on Section 7.4.2. This document only covers IGMP-MLD and PIMv6-PIMv4 scenarios. We also need to consider the scenario where it is layer 2 network between mAFTR and mB4. The architecture is as below: ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
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 : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Tina TSOU Envoyé : mardi 23 août 2011 03:58 À : softwires@ietf.org Objet : [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 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 ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Hi Tina, Please see inline. Cheers, Med De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Tina TSOU Envoyé : mercredi 24 août 2011 04:21 À : Jacni Qin Cc : softwires@ietf.org Objet : Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi Jacni, Thank you for your early reply. Have a good day. My replies are below. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: Jacni Qin [mailto:jac...@gmail.com] Sent: Tuesday, August 23, 2011 6:09 PM To: Tina TSOU Cc: softwires@ietf.org Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 hi, On Wed, Aug 24, 2011 at 8:02 AM, Tina TSOU tina.tsou.zout...@huawei.commailto:tina.tsou.zout...@huawei.com wrote: Hi all, Some more comments on draft-qin-softwire-dslite-multicast-04. #1 General comment: is there any consideration of interaction with unicast solutions, e.g., potential collocation or reuse of functions? Do we need some mapping or interaction table of the function elements or tunnels (IP-in-IP or IP-in-non-IP) to show the relationship with DS-Lite unicast solution? Jacni: As Yiu mentioned in another email, the co-location with unicast DS-Lite elements is more deployment specific, and I'm ok to remove the section 4.5. From the protocol perspective, I don't see there is necessary interaction with the unicast solution. [TT] Section 4.5 is good for the readers to understand the difference between unicast and multicast DS-Lite. I strongly suggest add some texts into this section like the co-location of multicast elements with unicast DS-Lite elements is more deployment specific. [Med] OK. We will do. #2 Section 6.2 Translation and encapsulation both uses the same mPrefix64 and uPrefix64, so mB4 could not determine whether to de-capsulate the packets only based on mPrefix64 and uPrefix64. Propose to change as it checks whether the group address is in the range of mPrefix64, the source address is in the range of uPrefix64 and whether the next header of IPv6 header is 4. Jacni:Currently, we only employ the encapsulation for date forwarding in the main text. [TT] I am not talking about translation solution in the main text. Even if in the encapsulation case, mB4 needs to determine whether to make de-capsulation or not. [Med] This excerpt from Section 6.2 explains the rule to follow: When the mB4 receives an IPv6 multicast packet, it checks whether the group address is in the range of mPrefix64 and the source address is in the range of uPrefix64. Does this answer your question? ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Bonjour Med, Ca va? Thank you for your deep insight and reply. When the IPv6 packet comes, how does mB4 know it should make encapsulation or translation if mPrefix64 and uPrefix64 are the same? As defined in section 6.3 of draft-boucadair-behave-64-multicast-address-formathttp://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04#ref-I-D.boucadair-behave-64-multicast-address-format, there is no need to reserve a bit in the IPv6 multicast address to separate between the translation and the encapsulation schemes. So when mPrefix64 and uPrefix64 are the same for both encapsulation and translation, mB4 could not make decision which operation to make. In this case, the IPv6 header itself can be used to identify encapsulation or translation. For example, if the next header of IPv6 header is 4, mB4 should make de-capsulation because there is IPv4 packet inside. If it is other value, translation may be needed. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange-ftgroup.com Sent: Tuesday, August 23, 2011 11:54 PM To: Tina TSOU; Jacni Qin Cc: softwires@ietf.org Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi Tina, Please see inline. Cheers, Med De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Tina TSOU Envoyé : mercredi 24 août 2011 04:21 À : Jacni Qin Cc : softwires@ietf.org Objet : Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi Jacni, Thank you for your early reply. Have a good day. My replies are below. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: Jacni Qin [mailto:jac...@gmail.com] Sent: Tuesday, August 23, 2011 6:09 PM To: Tina TSOU Cc: softwires@ietf.org Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 hi, On Wed, Aug 24, 2011 at 8:02 AM, Tina TSOU tina.tsou.zout...@huawei.commailto:tina.tsou.zout...@huawei.com wrote: Hi all, Some more comments on draft-qin-softwire-dslite-multicast-04. #1 General comment: is there any consideration of interaction with unicast solutions, e.g., potential collocation or reuse of functions? Do we need some mapping or interaction table of the function elements or tunnels (IP-in-IP or IP-in-non-IP) to show the relationship with DS-Lite unicast solution? Jacni: As Yiu mentioned in another email, the co-location with unicast DS-Lite elements is more deployment specific, and I'm ok to remove the section 4.5. From the protocol perspective, I don't see there is necessary interaction with the unicast solution. [TT] Section 4.5 is good for the readers to understand the difference between unicast and multicast DS-Lite. I strongly suggest add some texts into this section like the co-location of multicast elements with unicast DS-Lite elements is more deployment specific. [Med] OK. We will do. #2 Section 6.2 Translation and encapsulation both uses the same mPrefix64 and uPrefix64, so mB4 could not determine whether to de-capsulate the packets only based on mPrefix64 and uPrefix64. Propose to change as it checks whether the group address is in the range of mPrefix64, the source address is in the range of uPrefix64 and whether the next header of IPv6 header is 4. Jacni:Currently, we only employ the encapsulation for date forwarding in the main text. [TT] I am not talking about translation solution in the main text. Even if in the encapsulation case, mB4 needs to determine whether to make de-capsulation or not. [Med] This excerpt from Section 6.2 explains the rule to follow: When the mB4 receives an IPv6 multicast packet, it checks whether the group address is in the range of mPrefix64 and the source address is in the range of uPrefix64. Does this answer your question? ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
On Thu, Aug 25, 2011 at 3:16 AM, Tina TSOU tina.tsou.zout...@huawei.comwrote: ... #2 Section 6.2 Translation and encapsulation both uses the same mPrefix64 and uPrefix64, so mB4 could not determine whether to de-capsulate the packets only based on mPrefix64 and uPrefix64. Propose to change as it checks whether the group address is in the range of mPrefix64, the source address is in the range of uPrefix64 and whether the next header of IPv6 header is 4. Jacni:Currently, we only employ the encapsulation for date forwarding in the main text. [TT] I am not talking about translation solution in the main text. Even if in the encapsulation case, mB4 needs to determine whether to make de-capsulation or not. Jacni: In the case of encapsulation, the mB4 can determine that by checking whether the group address is within the mPrefix64 and the source address is within the uPrefix64, as what the 6.2 says. [TT1] When the packet comes, how does mB4 know it should make encapsulation or translation if mPrefix64 and uPrefix64 are the same? In this case, the next header of IPv6 header could be used for mB4 to determine. Jacni: Please see again my comments above, also your own. Thanks. Cheers, Jacni ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Hi Tina, What do you see new here in this scenario? mAFTR is a logical function, it would perform MLD PIMv4-Join interworking. This has been captured. If a vendor wants to make mAFTR also a L2 device, it would perform standard MLD snooping. What else is missing? Thanks, Yiu From: Tina TSOU tina.tsou.zout...@huawei.commailto:tina.tsou.zout...@huawei.com Date: Thu, 25 Aug 2011 02:11:18 + To: softwires@ietf.orgmailto:softwires@ietf.org softwires@ietf.orgmailto:softwires@ietf.org Subject: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi all, One more comment on Section 7.4.2. This document only covers IGMP-MLD and PIMv6-PIMv4 scenarios. We also need to consider the scenario where it is layer 2 network between mAFTR and mB4. The architecture is as below: / \ | IPv4 network | \/ : | ^ IPv4 Multicast : | : PIMv4 Join v | : +-+ |mAFTR | +-+ |:| | ^ IPv6 Multicast |:| | : (MLD Report) (IPv4 embedded) |.| ... . +---+ | MLD proxy/| | snooping | +---+ |:| | : MLD Report |v| | : +---+ | mB4| +---+ : | ^ IPv4 Multicast : | : IGMP Report v | : +---+ | IPv4 | | Receiver | +---+ B. R. Tina ___ Softwires mailing list Softwires@ietf.orgmailto:Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Thanks for the comments, inline please. On Tue, Aug 23, 2011 at 9:58 AM, Tina TSOU tina.tsou.zout...@huawei.comwrote: 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. Jacni: I don't see it, while you can post comments. Section 1: Editorial: at the end of the second paragraph, vastly consumed reads better in English as: consumed in vast quantities. Jacni: Sorry, EN is not my first language. Maybe we need the help from a native guy. 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. Jacni: No objection to add a sentence, but modified as which preserves the efficiency of using multicast for traffics forwarding. Section 2: Terminology: Multicast AFTR has connotations (IPv4 NAT) that simply aren't there. Suggestion: Multicast Transitional Border Gateway (mTBG). Jacni: I think the AFTR is a general item, see the similar comments raised in another thread about 4rd. 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: Jacni: Sorry, I don't agree. I think text in the paragraph following the bullet explains the scope clearly. 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. Jacni:That's what the current text means. 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 ... Jacni: The signalling things will be detailed in the signalling section. This is just a general description here. 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 Jacni: Oops, got it, thank you. 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: 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. 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. Jacni: We don't see the problems so far. 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. 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
Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
hi, On Wed, Aug 24, 2011 at 8:02 AM, Tina TSOU tina.tsou.zout...@huawei.comwrote: Hi all, Some more comments on draft-qin-softwire-dslite-multicast-04. #1 General comment: is there any consideration of interaction with unicast solutions, e.g., potential collocation or reuse of functions? Do we need some mapping or interaction table of the function elements or tunnels (IP-in-IP or IP-in-non-IP) to show the relationship with DS-Lite unicast solution? Jacni: As Yiu mentioned in another email, the co-location with unicast DS-Lite elements is more deployment specific, and I'm ok to remove the section 4.5. From the protocol perspective, I don't see there is necessary interaction with the unicast solution. #2 Section 6.2 Translation and encapsulation both uses the same mPrefix64 and uPrefix64, so mB4 could not determine whether to de-capsulate the packets only based on mPrefix64 and uPrefix64. Propose to change as it checks whether the group address is in the range of mPrefix64, the source address is in the range of uPrefix64 and whether the next header of IPv6 header is 4. Jacni:Currently, we only employ the encapsulation for date forwarding in the main text. Cheers, Jacni Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
hi, On Wed, Aug 24, 2011 at 10:21 AM, Tina TSOU tina.tsou.zout...@huawei.comwrote: ... #2 Section 6.2 Translation and encapsulation both uses the same mPrefix64 and uPrefix64, so mB4 could not determine whether to de-capsulate the packets only based on mPrefix64 and uPrefix64. Propose to change as it checks whether the group address is in the range of mPrefix64, the source address is in the range of uPrefix64 and whether the next header of IPv6 header is 4. Jacni:Currently, we only employ the encapsulation for date forwarding in the main text. [TT] I am not talking about translation solution in the main text. Even if in the encapsulation case, mB4 needs to determine whether to make de-capsulation or not. Jacni: In the case of encapsulation, the mB4 can determine that by checking whether the group address is within the mPrefix64 and the source address is within the uPrefix64, as what the 6.2 says. Cheers, Jacni ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
