Re: [Softwires] Softwire Interim Meeting in Beijing
+1, and we also hope to present the softwire mesh MIB Dear Chairs: Are there any plans to discuss the MIBs at the interim meeting? According to our softwire WG milestones, our MIBs also need more discussions. -1. MIBs are boring. ;-) cheers, Ole Best Regards Yu -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Alain Durand Sent: Monday, August 22, 2011 11:40 PM To: gjs...@gmail.com Cc: liziye; Ralph Droms (rdroms); Yong Cui; iesg-secret...@ietf.org; softwires@ietf.org Subject: Re: [Softwires] Softwire Interim Meeting in Beijing So far, I'd like the focus to be on stateless. We will see by the end of the week (end of the call for presentation) if we have time for multicast. Alain. Sent from my iPad On Aug 22, 2011, at 10:57 AM, Greg Shepherd gjs...@gmail.com wrote: Are there any plans to discuss solutions for multicast at the interim meeting? Thanks, Greg On Mon, Aug 22, 2011 at 3:57 AM, GangChen phdg...@gmail.com wrote: Dear Chairs, I suggest including draft-murakami-softwire-4v6-translation-00 into the agenda as well. We already had a presentation in last softwire meeting. It's reasonable to continue the discussion in the interim meeting Many thanks Gang 2011/8/19, Yong Cui cuiy...@tsinghua.edu.cn: Hi folks, We, softwire wg chairs, in agreement with our ADs, are announcing an interim meeting in Beijing on September 26 27. The date has been chosen adjacent to the BBF meeting in Shangai to minimize travel and visa issues. The interim meeting will focus on 'stateless' solutions in general and 4rd in particular. Expected outcome includes progress on 4rd spec, packet format, where to put IPv4 bits, port indications, DHCP option, tunneling vs translation, coexistence with other technologies, etc... --- Meeting Location recommended hotels Meeting venue: FIT Building, Tsinghua University, Beijing FIT Building is the first left building inside of the East Gate of Tsinghua Univeristy http://maps.google.com/maps/ms?msid=202779846620144871057.0004aad8ce367b982 9372msa=0ll=39.996906,116.331664spn=0.004044,0.008798 Recommended hotels: 1. Uniscenter (4 stars, 3 min walk) http://en.uniscenter.com/newEbiz1/EbizPortalFG/portal/html/index.html 2. Wenjin Hotel (5 stars, 10 min walk) http://www.wenjin.com.cn/ 3. Royal King Hotel (5 stars, 10 min by car) http://www.royalkinghotel.com/ Invitation letter If you need an invitation letter, please send the following info to Ms. Ziye Li: liz...@csnet1.cs.tsinghua.edu.cn. Surname: Given Name: Company: Address: Phone: Passport Number: Passport Exp. Date: Passport Issuing Country: - Further contact information Please contact Ms. Ziye Li if you have any question about Beijing/Tsinghua/Hotel/Meeting venue/visa/tour... liz...@csnet1.cs.tsinghua.edu.cn -- Alain, Yong ___ 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 ___ 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 ___ 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] Call for presentations for the interim meeting
Alain I would like to have a presentation our draft. http://tools.ietf.org/html/draft-sakura-6rd-datacenter-01 I was assigned time slot on IETF81,but I could not... This is informative 6rd draft for operators,I think. Please assign a slot for this. And if it is possible,please assign faster of time slot. Regards, -Shishio Alain Durand wrote: As we mentioned earlier, the softwire interim meeting will focus on 'stateless solutions'. If you'd like to present there, please send the chairs a note by Friday this week. Alain. ___ 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] Call for presentations for the interim meeting
isn't this interim there to discuss the new stateless approaches. not to be overflow meeting for whatever didn't make it on the agenda at the last IETF meeting? if we get time to spare fine, but I would certainly have liked this meeting to be focused on the stateless solutions. and with the number of drafts published I would think we have enough to fill a couple of days too. cheers, Ole On Aug 25, 2011, at 10:12 , Shishio Tsuchiya wrote: Alain I would like to have a presentation our draft. http://tools.ietf.org/html/draft-sakura-6rd-datacenter-01 I was assigned time slot on IETF81,but I could not... This is informative 6rd draft for operators,I think. Please assign a slot for this. And if it is possible,please assign faster of time slot. Regards, -Shishio Alain Durand wrote: As we mentioned earlier, the softwire interim meeting will focus on 'stateless solutions'. If you'd like to present there, please send the chairs a note by Friday this week. Alain. ___ 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] Call for presentations for the interim meeting
Ole Ok.I won't,if this interim will focuses discussion of new stateless solution and it is not enough time. And if it is possible,please assign faster of time slot. Let's move to lower priority of time slot. Regards, -Shishio Ole Troan wrote: isn't this interim there to discuss the new stateless approaches. not to be overflow meeting for whatever didn't make it on the agenda at the last IETF meeting? if we get time to spare fine, but I would certainly have liked this meeting to be focused on the stateless solutions. and with the number of drafts published I would think we have enough to fill a couple of days too. cheers, Ole On Aug 25, 2011, at 10:12 , Shishio Tsuchiya wrote: Alain I would like to have a presentation our draft. http://tools.ietf.org/html/draft-sakura-6rd-datacenter-01 I was assigned time slot on IETF81,but I could not... This is informative 6rd draft for operators,I think. Please assign a slot for this. And if it is possible,please assign faster of time slot. Regards, -Shishio Alain Durand wrote: As we mentioned earlier, the softwire interim meeting will focus on 'stateless solutions'. If you'd like to present there, please send the chairs a note by Friday this week. Alain. ___ 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] Call for presentations for the interim meeting
Hi, Alain and Yong, We would like to have a presentation of two related drafts in the interim meeting. https://datatracker.ietf.org/doc/draft-xli-behave-divi-pd/ https://datatracker.ietf.org/doc/draft-xli-behave-divi/ Please assign a slot for this. Thanks! Xing Li 于 2011/8/22 23:37, Alain Durand 写道: As we mentioned earlier, the softwire interim meeting will focus on 'stateless solutions'. If you'd like to present there, please send the chairs a note by Friday this week. Alain. ___ 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
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
[Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04
Hi all, In section 6.3, To avoid fragmentation, a service provider may increase the MTU size by 40 bytes on the IPv6 network or mAFTR and mB4 may use IPv6 Path MTU discovery. How to use IPv6 Path MTU discovery to avoid fragmentation? Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html ___ 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 section 6.3 of draft-qin-softwire-dslite-multicast-04
Hi, On Fri, Aug 26, 2011 at 10:36 AM, Tina TSOU tina.tsou.zout...@huawei.comwrote: Hi all, In section 6.3, To avoid fragmentation, a service provider may increase the MTU size by 40 bytes on the IPv6 network or mAFTR and mB4 may use IPv6 Path MTU discovery. How to use IPv6 Path MTU discovery to avoid fragmentation? Jacni: You can read RFC1981, thanks. 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
