Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02
Hi Stig, Thanks a lot for your comments. On 7/14/2012 Saturday 4:57 AM, Stig Venaas wrote: On 7/12/2012 8:20 PM, Jacni Qin wrote: Hi all, Please see below the text updated according to the comments received. Many thanks to Stig, Simon, Shailesh, and others for their review and discussions. Thanks, this addresses at least some of my concerns. Let me try to list the issues I mentioned in my review that I think may not be addressed. 1. Update the text to make it clear it is a generic solution, but with applicability to DS-Lite. We're trying to figure out what we can do on this. 2. It refers to draft-ietf-mboned-64-multicast-address-format-01. I think may need to wait and see what happens to this. It depends on discussion in the ipv6 wg whether this format will be chosen. The examples in this draft may need to be updated depending on the format chosen. Fine. 3. In 4.2 it says The MLD Querier (typically acts as the PIMv6 Designated Router), but if there are multiple routers, then the querier is typically not the DR. We just wanted to include the MLD-PIM inter-operations, while to avoid the confusion, we can remove the (typically acts as the PIMv6 Designated Router) 4. Talk about what tunnel types are used. Either pick a specific type, or I think better, explain how this solution can be used with different types. E.g. IPv4 in IPv6, and GRE. A note has been added, which says, Note: At this point, only IPv4-in-IPv6 encapsulation is defined; Whether or not to support other types of encapsulation is left for future consideration. 5. Security considerations should say something about scoping I think. How scopes for v4 and v6 may differ, and also how one can in a global IPv6 group specify a non-global IPv4 group... Some kind of filtering should be in place to protect against this. Could you help on this to propose some text? Thanks a lot. Apart from this I had only minor comments which hopefully will be addressed in the next version. Thanks for your comments, surely we'll try. Cheers, Jacni Stig 4.2. Multicast Distribution Tree Computation ... 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, and to pass the Reverse Path Forwarding (RPF) check on multicast devices. 4.3. Multicast Data Forwarding ... /* A note is added*/ Note: At this point, only IPv4-in-IPv6 encapsulation is defined; Whether or not to support other types of encapsulation is left for future consideration. 6.1. IGMP-MLD Interworking Function The IGMP-MLD Interworking Function combines the IGMP/MLD Proxying function and the address synthesizing operations. The IGMP/MLD Proxying function is specified in [RFC4605]. The address synthesizing is stateless and MUST follow [I-D.ietf-mboned-64-multicast-address-format] and [RFC6052]. The mB4 with the IGMP-MLD Interworking Function embedded relays between the IGMP domain and the MLD domain. The mB4 performs the host portion of the MLD protocol on the upstream interface. The composition of IPv6 membership in this context is constructed through address synthesizing operations and MUST synchronize with the membership database maintained in the IGMP domain. MLD messages will be forwarded natively towards the MLD Querier located upstream in the IPv6 network. The mB4 also performs the router portion of the IGMP protocol on the downstream interface(s). Refer to [RFC4605] for more details +--+ IGMP +---+ MLD +-+ | IPv4 |-| mB4 |-| MLD | | Receiver | | | | Querier | +--+ +---+ +-+ Figure 2: IGMP-MLD Interworking If SSM is deployed, the mB4 MUST construct the IPv6 source address (or retrieve the IPv4 source address) using the uPrefix64. The mB4 may create a membership database which associates the IPv4-IPv6 multicast groups with the interfaces (e.g., Wi-Fi and Wired Ethernet) facing IPv4 multicast receivers. 7.2. Processing PIM Message /* TIB is used to replace mRIB*/ 7.5. TTL/Scope The Scope field of IPv4-in-IPv6 multicast addresses should be valued accordingly (e.g, to E, Global scope;) in the deployment environment. This specification does not discuss the scope value that should be used. -- Cheers, Jacni On 5/27/2012 Sunday 10:34 PM, Yong Cui wrote: Hi folks, This is a wg last call on draft-ietf-softwire-dslite-multicast-02. http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-multicast/ As usual, please send editorial comments to the authors and substantive comments to the mailing
Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02
On 7/12/2012 8:20 PM, Jacni Qin wrote: Hi all, Please see below the text updated according to the comments received. Many thanks to Stig, Simon, Shailesh, and others for their review and discussions. Thanks, this addresses at least some of my concerns. Let me try to list the issues I mentioned in my review that I think may not be addressed. 1. Update the text to make it clear it is a generic solution, but with applicability to DS-Lite. 2. It refers to draft-ietf-mboned-64-multicast-address-format-01. I think may need to wait and see what happens to this. It depends on discussion in the ipv6 wg whether this format will be chosen. The examples in this draft may need to be updated depending on the format chosen. 3. In 4.2 it says The MLD Querier (typically acts as the PIMv6 Designated Router), but if there are multiple routers, then the querier is typically not the DR. 4. Talk about what tunnel types are used. Either pick a specific type, or I think better, explain how this solution can be used with different types. E.g. IPv4 in IPv6, and GRE. 5. Security considerations should say something about scoping I think. How scopes for v4 and v6 may differ, and also how one can in a global IPv6 group specify a non-global IPv4 group... Some kind of filtering should be in place to protect against this. Apart from this I had only minor comments which hopefully will be addressed in the next version. Stig 4.2. Multicast Distribution Tree Computation ... 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, and to pass the Reverse Path Forwarding (RPF) check on multicast devices. 4.3. Multicast Data Forwarding ... /* A note is added*/ Note: At this point, only IPv4-in-IPv6 encapsulation is defined; Whether or not to support other types of encapsulation is left for future consideration. 6.1. IGMP-MLD Interworking Function The IGMP-MLD Interworking Function combines the IGMP/MLD Proxying function and the address synthesizing operations. The IGMP/MLD Proxying function is specified in [RFC4605]. The address synthesizing is stateless and MUST follow [I-D.ietf-mboned-64-multicast-address-format] and [RFC6052]. The mB4 with the IGMP-MLD Interworking Function embedded relays between the IGMP domain and the MLD domain. The mB4 performs the host portion of the MLD protocol on the upstream interface. The composition of IPv6 membership in this context is constructed through address synthesizing operations and MUST synchronize with the membership database maintained in the IGMP domain. MLD messages will be forwarded natively towards the MLD Querier located upstream in the IPv6 network. The mB4 also performs the router portion of the IGMP protocol on the downstream interface(s). Refer to [RFC4605] for more details +--+ IGMP +---+ MLD +-+ | IPv4 |-| mB4 |-| MLD | | Receiver | | | | Querier | +--+ +---+ +-+ Figure 2: IGMP-MLD Interworking If SSM is deployed, the mB4 MUST construct the IPv6 source address (or retrieve the IPv4 source address) using the uPrefix64. The mB4 may create a membership database which associates the IPv4-IPv6 multicast groups with the interfaces (e.g., Wi-Fi and Wired Ethernet) facing IPv4 multicast receivers. 7.2. Processing PIM Message /* TIB is used to replace mRIB*/ 7.5. TTL/Scope The Scope field of IPv4-in-IPv6 multicast addresses should be valued accordingly (e.g, to E, Global scope;) in the deployment environment. This specification does not discuss the scope value that should be used. -- Cheers, Jacni On 5/27/2012 Sunday 10:34 PM, Yong Cui wrote: Hi folks, This is a wg last call on draft-ietf-softwire-dslite-multicast-02. http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-multicast/ As usual, please send editorial comments to the authors and substantive comments to the mailing list. This wg last call will end on June 10 at 12pm EDT. Yong 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] WG last call on draft-ietf-softwire-dslite-multicast-02
Hi all, Please see below the text updated according to the comments received. Many thanks to Stig, Simon, Shailesh, and others for their review and discussions. 4.2. Multicast Distribution Tree Computation ... 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, and to pass the Reverse Path Forwarding (RPF) check on multicast devices. 4.3. Multicast Data Forwarding ... /* A note is added*/ Note: At this point, only IPv4-in-IPv6 encapsulation is defined; Whether or not to support other types of encapsulation is left for future consideration. 6.1. IGMP-MLD Interworking Function The IGMP-MLD Interworking Function combines the IGMP/MLD Proxying function and the address synthesizing operations. The IGMP/MLD Proxying function is specified in [RFC4605]. The address synthesizing is stateless and MUST follow [I-D.ietf-mboned-64-multicast-address-format] and [RFC6052]. The mB4 with the IGMP-MLD Interworking Function embedded relays between the IGMP domain and the MLD domain. The mB4 performs the host portion of the MLD protocol on the upstream interface. The composition of IPv6 membership in this context is constructed through address synthesizing operations and MUST synchronize with the membership database maintained in the IGMP domain. MLD messages will be forwarded natively towards the MLD Querier located upstream in the IPv6 network. The mB4 also performs the router portion of the IGMP protocol on the downstream interface(s). Refer to [RFC4605] for more details +--+ IGMP +---+ MLD +-+ | IPv4 |-| mB4 |-| MLD | | Receiver | | | | Querier | +--+ +---+ +-+ Figure 2: IGMP-MLD Interworking If SSM is deployed, the mB4 MUST construct the IPv6 source address (or retrieve the IPv4 source address) using the uPrefix64. The mB4 may create a membership database which associates the IPv4-IPv6 multicast groups with the interfaces (e.g., Wi-Fi and Wired Ethernet) facing IPv4 multicast receivers. 7.2. Processing PIM Message /* TIB is used to replace mRIB*/ 7.5. TTL/Scope The Scope field of IPv4-in-IPv6 multicast addresses should be valued accordingly (e.g, to E, Global scope;) in the deployment environment. This specification does not discuss the scope value that should be used. -- Cheers, Jacni On 5/27/2012 Sunday 10:34 PM, Yong Cui wrote: Hi folks, This is a wg last call on draft-ietf-softwire-dslite-multicast-02. http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-multicast/ As usual, please send editorial comments to the authors and substantive comments to the mailing list. This wg last call will end on June 10 at 12pm EDT. Yong 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] WG last call on draft-ietf-softwire-dslite-multicast-02
Re-, Thanks a lot for your review and comments, we'll update it accordingly. Cheers, Jacni On 6/28/2012 Thursday 12:42 AM, Shailesh Suman wrote: Hi Lee, Thanks for your reply. It clarifies some of my queries now. Hope to see the revison tries to address these points. Regards.. -Shailesh On Tue, Jun 26, 2012 at 7:11 PM, Lee, Yiu yiu_...@cable.comcast.com wrote: Hi Shailesh, Thanks very much of reviewing the draft. Please read comments inline: On 6/26/12 8:07 AM, Shailesh Suman sumanshail...@gmail.com wrote: Hi All, I see few points of this draft need to be addressed to address complete solution. 1). Section 6.2 mentions the mB4 must drop non-matching (mPrefix64 and uPrefix64) packets silently. There can be scenarios, where some of LAN Multicast receivers are supporting native IPv6. How will such packets reach the v6 Multicast Receivers, in case they get silently discarded by mB4. Hence, the hybrid scenario of having both v6 and v4 Multicast Receivers in LAN should also be looked into. [YL] mB4 is a logical function and should be implemented along side with normal MLD listener in the same CPE. If the multicast address header contains mPrefix64 and uPrefix64, it should pass to mB4. Otherwise, the normal MLD listener will handle it. That sentence tries to prevent normal multicast message from accidentally passing to mB4. 2). It is also possible for LAN to have Multicast Originators rather than only Multicast Receivers. This solution currently restricts the scope to downstream Multicast traffic only and there should be some exploration for Originators as well. [YL] Our main focus on this to support home user (i.e. IPTV service). You can find more discussion in http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00. This is why we limit the scope. We can add more words to expect our motives. 3). Fragmentation issues can surface for any transition techniques. However for DS-Lite (applicable to Unicast traffic only) Path-MTU can come for rescue. But for Multicast traffic Path-MTU can not be run. This can lead to Fragmentation and Assembly Overheads in mAFTR and mB4 respectively. I think, addressing these points would be vital for this I.D. [YL] I agree. We will propose some text in next revision. Thanks, Yiu Regards -Shailesh Message: 1 Date: Tue, 26 Jun 2012 07:36:41 +0800 From: Jacni Qin ja...@jacni.com To: sarik...@ieee.org Cc: Softwires-wg softwires@ietf.org, Behcet Sarikaya sarikaya2...@gmail.com Subject: Re: [Softwires] [SPAM] Re: WG last call on draft-ietf-softwire-dslite-multicast-02 Message-ID: 4fe8f609.1040...@jacni.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Re-, On 6/26/2012 Tuesday 2:50 AM, Behcet Sarikaya wrote: On Mon, Jun 25, 2012 at 1:09 AM, Jacni Qinja...@jacni.com wrote: Hi Behcet, all, On Friday, June 22, 2012 2:23:34 AM, Behcet Sarikaya wrote: Folks, We have published revised version of our draft on multicast extensions to DS-Lite at http://www.ietf.org/id/draft-sarikaya-softwire-dslitemulticast-01.txt It's been discussed on the list and in the 81st meeting, and concluded quite clearly by the WG why this is abandoned. It tunnels the IGMP packets upwards, replicates the multicast traffic per tunnel, opposite to the property of multicast technology. And these are problems we're trying to solve. draft-ietf-softwire-dslite-multicast-02 has nothing to do with DS-Lite and therefore it is not a DS-Lite multicast extensions document as the charter requires. OTOH, draft-sarikaya-softwire-dslitemulticast-01.txt integrates multicast into DS-Lite tunnel. It is not against multicast technology. In this way, the efficiency is lost. If operators put the AFTR box deeply in the network, far from the end users, as you process the singling messages and replicate of traffic per tunnel, the network and the box will crash because of the huge burden. There is no necessity to initiate that kind of discussion once again. I did not start this discussion. Please check the list. Again please see above, or check the archive and the offlist messages where we've explained it to you in detail. Cheers, Jacni Regards. Behcet Cheers, Jacni We think that this draft should be part of draft-ietf-softwire-dslite-multicast. Regards, Behcet ___ 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] WG last call on draft-ietf-softwire-dslite-multicast-02
Hi Lee, Thanks for your reply. It clarifies some of my queries now. Hope to see the revison tries to address these points. Regards.. -Shailesh On Tue, Jun 26, 2012 at 7:11 PM, Lee, Yiu yiu_...@cable.comcast.com wrote: Hi Shailesh, Thanks very much of reviewing the draft. Please read comments inline: On 6/26/12 8:07 AM, Shailesh Suman sumanshail...@gmail.com wrote: Hi All, I see few points of this draft need to be addressed to address complete solution. 1). Section 6.2 mentions the mB4 must drop non-matching (mPrefix64 and uPrefix64) packets silently. There can be scenarios, where some of LAN Multicast receivers are supporting native IPv6. How will such packets reach the v6 Multicast Receivers, in case they get silently discarded by mB4. Hence, the hybrid scenario of having both v6 and v4 Multicast Receivers in LAN should also be looked into. [YL] mB4 is a logical function and should be implemented along side with normal MLD listener in the same CPE. If the multicast address header contains mPrefix64 and uPrefix64, it should pass to mB4. Otherwise, the normal MLD listener will handle it. That sentence tries to prevent normal multicast message from accidentally passing to mB4. 2). It is also possible for LAN to have Multicast Originators rather than only Multicast Receivers. This solution currently restricts the scope to downstream Multicast traffic only and there should be some exploration for Originators as well. [YL] Our main focus on this to support home user (i.e. IPTV service). You can find more discussion in http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00. This is why we limit the scope. We can add more words to expect our motives. 3). Fragmentation issues can surface for any transition techniques. However for DS-Lite (applicable to Unicast traffic only) Path-MTU can come for rescue. But for Multicast traffic Path-MTU can not be run. This can lead to Fragmentation and Assembly Overheads in mAFTR and mB4 respectively. I think, addressing these points would be vital for this I.D. [YL] I agree. We will propose some text in next revision. Thanks, Yiu Regards -Shailesh Message: 1 Date: Tue, 26 Jun 2012 07:36:41 +0800 From: Jacni Qin ja...@jacni.com To: sarik...@ieee.org Cc: Softwires-wg softwires@ietf.org, Behcet Sarikaya sarikaya2...@gmail.com Subject: Re: [Softwires] [SPAM] Re: WG last call on draft-ietf-softwire-dslite-multicast-02 Message-ID: 4fe8f609.1040...@jacni.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Re-, On 6/26/2012 Tuesday 2:50 AM, Behcet Sarikaya wrote: On Mon, Jun 25, 2012 at 1:09 AM, Jacni Qinja...@jacni.com wrote: Hi Behcet, all, On Friday, June 22, 2012 2:23:34 AM, Behcet Sarikaya wrote: Folks, We have published revised version of our draft on multicast extensions to DS-Lite at http://www.ietf.org/id/draft-sarikaya-softwire-dslitemulticast-01.txt It's been discussed on the list and in the 81st meeting, and concluded quite clearly by the WG why this is abandoned. It tunnels the IGMP packets upwards, replicates the multicast traffic per tunnel, opposite to the property of multicast technology. And these are problems we're trying to solve. draft-ietf-softwire-dslite-multicast-02 has nothing to do with DS-Lite and therefore it is not a DS-Lite multicast extensions document as the charter requires. OTOH, draft-sarikaya-softwire-dslitemulticast-01.txt integrates multicast into DS-Lite tunnel. It is not against multicast technology. In this way, the efficiency is lost. If operators put the AFTR box deeply in the network, far from the end users, as you process the singling messages and replicate of traffic per tunnel, the network and the box will crash because of the huge burden. There is no necessity to initiate that kind of discussion once again. I did not start this discussion. Please check the list. Again please see above, or check the archive and the offlist messages where we've explained it to you in detail. Cheers, Jacni Regards. Behcet Cheers, Jacni We think that this draft should be part of draft-ietf-softwire-dslite-multicast. Regards, Behcet ___ 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] WG last call on draft-ietf-softwire-dslite-multicast-02
Hi All, I see few points of this draft need to be addressed to address complete solution. 1). Section 6.2 mentions the mB4 must drop non-matching (mPrefix64 and uPrefix64) packets silently. There can be scenarios, where some of LAN Multicast receivers are supporting native IPv6. How will such packets reach the v6 Multicast Receivers, in case they get silently discarded by mB4. Hence, the hybrid scenario of having both v6 and v4 Multicast Receivers in LAN should also be looked into. 2). It is also possible for LAN to have Multicast Originators rather than only Multicast Receivers. This solution currently restricts the scope to downstream Multicast traffic only and there should be some exploration for Originators as well. 3). Fragmentation issues can surface for any transition techniques. However for DS-Lite (applicable to Unicast traffic only) Path-MTU can come for rescue. But for Multicast traffic Path-MTU can not be run. This can lead to Fragmentation and Assembly Overheads in mAFTR and mB4 respectively. I think, addressing these points would be vital for this I.D. Regards -Shailesh Message: 1 Date: Tue, 26 Jun 2012 07:36:41 +0800 From: Jacni Qin ja...@jacni.com To: sarik...@ieee.org Cc: Softwires-wg softwires@ietf.org, Behcet Sarikaya sarikaya2...@gmail.com Subject: Re: [Softwires] [SPAM] Re: WG last call on draft-ietf-softwire-dslite-multicast-02 Message-ID: 4fe8f609.1040...@jacni.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Re-, On 6/26/2012 Tuesday 2:50 AM, Behcet Sarikaya wrote: On Mon, Jun 25, 2012 at 1:09 AM, Jacni Qinja...@jacni.com wrote: Hi Behcet, all, On Friday, June 22, 2012 2:23:34 AM, Behcet Sarikaya wrote: Folks, We have published revised version of our draft on multicast extensions to DS-Lite at http://www.ietf.org/id/draft-sarikaya-softwire-dslitemulticast-01.txt It's been discussed on the list and in the 81st meeting, and concluded quite clearly by the WG why this is abandoned. It tunnels the IGMP packets upwards, replicates the multicast traffic per tunnel, opposite to the property of multicast technology. And these are problems we're trying to solve. draft-ietf-softwire-dslite-multicast-02 has nothing to do with DS-Lite and therefore it is not a DS-Lite multicast extensions document as the charter requires. OTOH, draft-sarikaya-softwire-dslitemulticast-01.txt integrates multicast into DS-Lite tunnel. It is not against multicast technology. In this way, the efficiency is lost. If operators put the AFTR box deeply in the network, far from the end users, as you process the singling messages and replicate of traffic per tunnel, the network and the box will crash because of the huge burden. There is no necessity to initiate that kind of discussion once again. I did not start this discussion. Please check the list. Again please see above, or check the archive and the offlist messages where we've explained it to you in detail. Cheers, Jacni Regards. Behcet Cheers, Jacni We think that this draft should be part of draft-ietf-softwire-dslite-multicast. Regards, Behcet ___ 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] WG last call on draft-ietf-softwire-dslite-multicast-02
Hi Shailesh, Thanks very much of reviewing the draft. Please read comments inline: On 6/26/12 8:07 AM, Shailesh Suman sumanshail...@gmail.com wrote: Hi All, I see few points of this draft need to be addressed to address complete solution. 1). Section 6.2 mentions the mB4 must drop non-matching (mPrefix64 and uPrefix64) packets silently. There can be scenarios, where some of LAN Multicast receivers are supporting native IPv6. How will such packets reach the v6 Multicast Receivers, in case they get silently discarded by mB4. Hence, the hybrid scenario of having both v6 and v4 Multicast Receivers in LAN should also be looked into. [YL] mB4 is a logical function and should be implemented along side with normal MLD listener in the same CPE. If the multicast address header contains mPrefix64 and uPrefix64, it should pass to mB4. Otherwise, the normal MLD listener will handle it. That sentence tries to prevent normal multicast message from accidentally passing to mB4. 2). It is also possible for LAN to have Multicast Originators rather than only Multicast Receivers. This solution currently restricts the scope to downstream Multicast traffic only and there should be some exploration for Originators as well. [YL] Our main focus on this to support home user (i.e. IPTV service). You can find more discussion in http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00. This is why we limit the scope. We can add more words to expect our motives. 3). Fragmentation issues can surface for any transition techniques. However for DS-Lite (applicable to Unicast traffic only) Path-MTU can come for rescue. But for Multicast traffic Path-MTU can not be run. This can lead to Fragmentation and Assembly Overheads in mAFTR and mB4 respectively. I think, addressing these points would be vital for this I.D. [YL] I agree. We will propose some text in next revision. Thanks, Yiu Regards -Shailesh Message: 1 Date: Tue, 26 Jun 2012 07:36:41 +0800 From: Jacni Qin ja...@jacni.com To: sarik...@ieee.org Cc: Softwires-wg softwires@ietf.org, Behcet Sarikaya sarikaya2...@gmail.com Subject: Re: [Softwires] [SPAM] Re: WG last call on draft-ietf-softwire-dslite-multicast-02 Message-ID: 4fe8f609.1040...@jacni.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Re-, On 6/26/2012 Tuesday 2:50 AM, Behcet Sarikaya wrote: On Mon, Jun 25, 2012 at 1:09 AM, Jacni Qinja...@jacni.com wrote: Hi Behcet, all, On Friday, June 22, 2012 2:23:34 AM, Behcet Sarikaya wrote: Folks, We have published revised version of our draft on multicast extensions to DS-Lite at http://www.ietf.org/id/draft-sarikaya-softwire-dslitemulticast-01.txt It's been discussed on the list and in the 81st meeting, and concluded quite clearly by the WG why this is abandoned. It tunnels the IGMP packets upwards, replicates the multicast traffic per tunnel, opposite to the property of multicast technology. And these are problems we're trying to solve. draft-ietf-softwire-dslite-multicast-02 has nothing to do with DS-Lite and therefore it is not a DS-Lite multicast extensions document as the charter requires. OTOH, draft-sarikaya-softwire-dslitemulticast-01.txt integrates multicast into DS-Lite tunnel. It is not against multicast technology. In this way, the efficiency is lost. If operators put the AFTR box deeply in the network, far from the end users, as you process the singling messages and replicate of traffic per tunnel, the network and the box will crash because of the huge burden. There is no necessity to initiate that kind of discussion once again. I did not start this discussion. Please check the list. Again please see above, or check the archive and the offlist messages where we've explained it to you in detail. Cheers, Jacni Regards. Behcet Cheers, Jacni We think that this draft should be part of draft-ietf-softwire-dslite-multicast. Regards, Behcet ___ 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 smime.p7s Description: S/MIME cryptographic signature ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02
Folks, We have published revised version of our draft on multicast extensions to DS-Lite at http://www.ietf.org/id/draft-sarikaya-softwire-dslitemulticast-01.txt We think that this draft should be part of draft-ietf-softwire-dslite-multicast. Regards, Behcet ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02
Behcet, If you are suggesting we need get rid of multicast capabilities and use unicast between the AFTR and B4, I still claim this is a bad design choice. The rationale for the design documented in the draft is as follows (excerpt from the draft): If customers have to access IPv4 multicast-based services through DS- Lite environment, Address Family Transition Router (AFTR) devices will have to process all the IGMP Report messages [RFC2236] [RFC3376] that have been forwarded by the CPE into the IPv4-in-IPv6 tunnels. From that standpoint, AFTR devices are likely to behave as a replication point for downstream multicast traffic. And the multicast packets will be replicated for each tunnel endpoint where IPv4 receivers are connected to. This kind of DS-Lite environment raises two major issues: 1. The IPv6 network loses the benefits of the multicast traffic forwarding efficiency because it is unable to deterministically replicate the data as close to the receivers as possible. As a consequence, the downstream bandwidth in the IPv6 network will be vastly consumed by sending multicast data over a unicast infrastructure. 2. The AFTR is responsible for replicating multicast traffic and forwarding it into each tunnel endpoint connecting IPv4 receivers that have explicitly asked for the corresponding contents. This process may greatly consume AFTR's resources and overload the AFTR. This document specifies an extension to the DS-Lite model to deliver IPv4 multicast services to IPv4 clients over an IPv6 multicast- enabled network. For me, DS-Lite model is not only what is documented in RFC6333 but covers also stateless A+P including MAP and 4rd. Hope this clarifies your concern. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Behcet Sarikaya Envoyé : mercredi 13 juin 2012 00:23 À : Lee, Yiu Cc : softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Hi Yiu, The solution in this draft is generic, it simply leaves DS-Lite aside and builds its own stuff. I think this fact has been alluded to by the co-authors. This should change. Saying that a solution that integrates with DS-Lite is technically poor solution is saying that DS-Lite is technically poor solution. Behcet On Tue, Jun 12, 2012 at 3:56 PM, Lee, Yiu yiu_...@cable.comcast.com wrote: Hi Behect, You confuse me. 4.3 said this: When the mAFTR receives an IPv4 multicast packet, it will encapsulate the packet into an IPv6 multicast packet using the IPv4-embedded IPv6 multicast address as the destination address and an IPv4-embedded IPv6 unicast address as the source address. The data packets are tunneled over IPv6 hub by hub. That said, the tunnel isn't end-to-end. Thanks, Yiu On 6/12/12 4:30 PM, Behcet Sarikaya sarikaya2...@gmail.com wrote: It is not the case in the draft currently, check Sections 4.3 6.2. Behcet ___ 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] WG last call on draft-ietf-softwire-dslite-multicast-02
Re-, Did you read draft-ietf-softwire-dslite-multicast? I have some doubts given your message below. Cheers, Med -Message d'origine- De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Envoyé : lundi 11 juin 2012 18:08 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Hi Med, Thanks for your kind reply. I was talking about http://tools.ietf.org/html/draft-sarikaya-softwire-dslite6rdmul ticast-00 (which is now expired, I'll explain why below) Profiting the occasion, let me clarify that the chairs, Alain initially asked the two drafts to be merged. We favored the merger but Med was against. draft-ietf-softwire-dslite-multicast-02 presents a generic v4 to v6 multicast translation technique and as has been indicated such an approach has nothing to do with DS-Lite, i.e. DS-Lite does not translate unicast v4 packets into unicast v6 packets. I hope this is well understood. As such, draft-ietf-softwire-dslite-multicast-02 is suitable for NAT64, (remind you that there is already a multicast solution draft for NAT64). Regards, Behcet On Mon, Jun 11, 2012 at 1:15 AM, mohamed.boucad...@orange.com wrote: Hi Behcet, I failed to understand the point you are trying to make. The current situations is: * this document provides multicast extension to deliver multicast to DS-Lite serviced customers * we rely on multicast capabilities, as such no AMT-like considerations are included * the proposed solution is generic and can be deployed in any 4-6-4 use case What should be revised? Thanks for your help. Cheers, Med -Message d'origine- De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Envoyé : vendredi 8 juin 2012 17:35 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Wojciech Dec; Stig Venaas; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Hi Med, I agree with Woj. I do not favor moving this draft to somewhere else. Instead this draft should be revised to make it Multicast extensions to DS-Lite as in the charter. There is enough time to do it. Regards, Behcet On Fri, Jun 8, 2012 at 3:43 AM, mohamed.boucad...@orange.com wrote: Hi Woj, Your comment is valid. The point I wanted to make is to recall the initial motivation of this draft: solve an issue raised by DS-Lite people. Evidently, the proposed approach can be deployed in any 4-6-4 scenario. This will be reflected in the updated version of the draft. Cheers, Med De : Wojciech Dec [mailto:wdec.i...@gmail.com] Envoyé : vendredi 8 juin 2012 09:57 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : sarik...@ieee.org; Stig Venaas; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Hello Med, there is no dependency here on ds-lite, ie This has all the hallmarks of a standalone solution, which will almost certainly be implemented as such, and one that will work with or without ds-lite for unicast. Regards, Woj. On 8 June 2012 07:48, mohamed.boucad...@orange.com wrote: Re-, May I re-iterate: * The draft is designed to allow the delivery of multicast services to DS-Lite serviced customers. * The draft proposes multicast extensions and not unicast ones. Cheers, Med -Message d'origine- De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Envoyé : jeudi 7 juin 2012 20:20 À : Stig Venaas Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 On Thu, Jun 7, 2012 at 12:48 PM, Stig Venaas s...@venaas.com wrote: On 6/7/2012 10:08 AM, Behcet Sarikaya wrote: On Thu, Jun 7, 2012 at 8:07 AM,mohamed.boucad...@orange.com wrote: So you are saying that this draft does not correspond to Multicast extensions for DS-Lite? I sent a separate review, but anyway, it is not an extension to DS-Lite as I see it. It is a completely generic approach for tunneling v6 through v4. It can certainly be deployed in DS-Lite scenarios, but it is much more generic. I would like the title and the text to reflect that. So it means that this draft does not correspond to Softwire charter item and we discover this quite late in the process. My recommendation to the chairs is to read and double check the draft before making an adoption call, especially if there is choice. As I mentioned in my mboned mail, in multicast transition I think the right approach is to agree to the fact that most of the host's communication will be unicast. For unicast, v4-v6 transition has already been well analyzed and several protocols have been specified. Multicast extensions to those protocols are what we need. Regards, Behcet ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org
Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02
Well, it is still in the Softwires domain if it tunnels the multicast data, is it not? On 12/06/2012 4:11 PM, Behcet Sarikaya wrote: I think that a decision should be made on this draft. If it is going to present a generic solution it could be fine but then such a draft does not meet Softwire charter item so it can not stay in Softwire. My suggestion is to make it specific to DS-Lite so that it stays in Softwire and meets the charter item. I believe this was Alain's intention when he asked the two drafts to be merged. Regards, Behcet ... ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02
On Tue, Jun 12, 2012 at 3:16 PM, Tom Taylor tom.taylor.s...@gmail.com wrote: Well, it is still in the Softwires domain if it tunnels the multicast data, is it not? It is not the case in the draft currently, check Sections 4.3 6.2. Behcet On 12/06/2012 4:11 PM, Behcet Sarikaya wrote: I think that a decision should be made on this draft. If it is going to present a generic solution it could be fine but then such a draft does not meet Softwire charter item so it can not stay in Softwire. My suggestion is to make it specific to DS-Lite so that it stays in Softwire and meets the charter item. I believe this was Alain's intention when he asked the two drafts to be merged. Regards, Behcet ... ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02
Hi Behect, You confuse me. 4.3 said this: When the mAFTR receives an IPv4 multicast packet, it will encapsulate the packet into an IPv6 multicast packet using the IPv4-embedded IPv6 multicast address as the destination address and an IPv4-embedded IPv6 unicast address as the source address. The data packets are tunneled over IPv6 hub by hub. That said, the tunnel isn't end-to-end. Thanks, Yiu On 6/12/12 4:30 PM, Behcet Sarikaya sarikaya2...@gmail.com wrote: It is not the case in the draft currently, check Sections 4.3 6.2. Behcet smime.p7s Description: S/MIME cryptographic signature ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02
+1 On 6/12/12 4:46 PM, Stig Venaas s...@venaas.com wrote: On 6/12/2012 1:11 PM, Behcet Sarikaya wrote: I think that a decision should be made on this draft. If it is going to present a generic solution it could be fine but then such a draft does not meet Softwire charter item so it can not stay in Softwire. My suggestion is to make it specific to DS-Lite so that it stays in Softwire and meets the charter item. What do you mean by making it specific to DS-Lite? Are you talking about a different technical solution, or just wording? Right now the technical solution is generic, and I think that is great. While the wording seems DS-Lite specific to me. I don't like the idea of doing something DS-Lite specific, unless one can come up with a better technical solution that way. I think the technical solution in this draft is fine. Please let's not change it into a poor technical solution just to satisfy possible charter considerations. Stig I believe this was Alain's intention when he asked the two drafts to be merged. Regards, Behcet On Tue, Jun 12, 2012 at 3:34 AM, Jacni Qinja...@jacni.com wrote: 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
Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02
Hi Behcet, I failed to understand the point you are trying to make. The current situations is: * this document provides multicast extension to deliver multicast to DS-Lite serviced customers * we rely on multicast capabilities, as such no AMT-like considerations are included * the proposed solution is generic and can be deployed in any 4-6-4 use case What should be revised? Thanks for your help. Cheers, Med -Message d'origine- De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Envoyé : vendredi 8 juin 2012 17:35 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Wojciech Dec; Stig Venaas; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Hi Med, I agree with Woj. I do not favor moving this draft to somewhere else. Instead this draft should be revised to make it Multicast extensions to DS-Lite as in the charter. There is enough time to do it. Regards, Behcet On Fri, Jun 8, 2012 at 3:43 AM, mohamed.boucad...@orange.com wrote: Hi Woj, Your comment is valid. The point I wanted to make is to recall the initial motivation of this draft: solve an issue raised by DS-Lite people. Evidently, the proposed approach can be deployed in any 4-6-4 scenario. This will be reflected in the updated version of the draft. Cheers, Med De : Wojciech Dec [mailto:wdec.i...@gmail.com] Envoyé : vendredi 8 juin 2012 09:57 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : sarik...@ieee.org; Stig Venaas; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Hello Med, there is no dependency here on ds-lite, ie This has all the hallmarks of a standalone solution, which will almost certainly be implemented as such, and one that will work with or without ds-lite for unicast. Regards, Woj. On 8 June 2012 07:48, mohamed.boucad...@orange.com wrote: Re-, May I re-iterate: * The draft is designed to allow the delivery of multicast services to DS-Lite serviced customers. * The draft proposes multicast extensions and not unicast ones. Cheers, Med -Message d'origine- De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Envoyé : jeudi 7 juin 2012 20:20 À : Stig Venaas Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 On Thu, Jun 7, 2012 at 12:48 PM, Stig Venaas s...@venaas.com wrote: On 6/7/2012 10:08 AM, Behcet Sarikaya wrote: On Thu, Jun 7, 2012 at 8:07 AM,mohamed.boucad...@orange.com wrote: So you are saying that this draft does not correspond to Multicast extensions for DS-Lite? I sent a separate review, but anyway, it is not an extension to DS-Lite as I see it. It is a completely generic approach for tunneling v6 through v4. It can certainly be deployed in DS-Lite scenarios, but it is much more generic. I would like the title and the text to reflect that. So it means that this draft does not correspond to Softwire charter item and we discover this quite late in the process. My recommendation to the chairs is to read and double check the draft before making an adoption call, especially if there is choice. As I mentioned in my mboned mail, in multicast transition I think the right approach is to agree to the fact that most of the host's communication will be unicast. For unicast, v4-v6 transition has already been well analyzed and several protocols have been specified. Multicast extensions to those protocols are what we need. Regards, Behcet ___ 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] WG last call on draft-ietf-softwire-dslite-multicast-02
Hi Med, Thanks for your kind reply. I was talking about http://tools.ietf.org/html/draft-sarikaya-softwire-dslite6rdmulticast-00 (which is now expired, I'll explain why below) Profiting the occasion, let me clarify that the chairs, Alain initially asked the two drafts to be merged. We favored the merger but Med was against. draft-ietf-softwire-dslite-multicast-02 presents a generic v4 to v6 multicast translation technique and as has been indicated such an approach has nothing to do with DS-Lite, i.e. DS-Lite does not translate unicast v4 packets into unicast v6 packets. I hope this is well understood. As such, draft-ietf-softwire-dslite-multicast-02 is suitable for NAT64, (remind you that there is already a multicast solution draft for NAT64). Regards, Behcet On Mon, Jun 11, 2012 at 1:15 AM, mohamed.boucad...@orange.com wrote: Hi Behcet, I failed to understand the point you are trying to make. The current situations is: * this document provides multicast extension to deliver multicast to DS-Lite serviced customers * we rely on multicast capabilities, as such no AMT-like considerations are included * the proposed solution is generic and can be deployed in any 4-6-4 use case What should be revised? Thanks for your help. Cheers, Med -Message d'origine- De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Envoyé : vendredi 8 juin 2012 17:35 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Wojciech Dec; Stig Venaas; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Hi Med, I agree with Woj. I do not favor moving this draft to somewhere else. Instead this draft should be revised to make it Multicast extensions to DS-Lite as in the charter. There is enough time to do it. Regards, Behcet On Fri, Jun 8, 2012 at 3:43 AM, mohamed.boucad...@orange.com wrote: Hi Woj, Your comment is valid. The point I wanted to make is to recall the initial motivation of this draft: solve an issue raised by DS-Lite people. Evidently, the proposed approach can be deployed in any 4-6-4 scenario. This will be reflected in the updated version of the draft. Cheers, Med De : Wojciech Dec [mailto:wdec.i...@gmail.com] Envoyé : vendredi 8 juin 2012 09:57 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : sarik...@ieee.org; Stig Venaas; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Hello Med, there is no dependency here on ds-lite, ie This has all the hallmarks of a standalone solution, which will almost certainly be implemented as such, and one that will work with or without ds-lite for unicast. Regards, Woj. On 8 June 2012 07:48, mohamed.boucad...@orange.com wrote: Re-, May I re-iterate: * The draft is designed to allow the delivery of multicast services to DS-Lite serviced customers. * The draft proposes multicast extensions and not unicast ones. Cheers, Med -Message d'origine- De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Envoyé : jeudi 7 juin 2012 20:20 À : Stig Venaas Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 On Thu, Jun 7, 2012 at 12:48 PM, Stig Venaas s...@venaas.com wrote: On 6/7/2012 10:08 AM, Behcet Sarikaya wrote: On Thu, Jun 7, 2012 at 8:07 AM,mohamed.boucad...@orange.com wrote: So you are saying that this draft does not correspond to Multicast extensions for DS-Lite? I sent a separate review, but anyway, it is not an extension to DS-Lite as I see it. It is a completely generic approach for tunneling v6 through v4. It can certainly be deployed in DS-Lite scenarios, but it is much more generic. I would like the title and the text to reflect that. So it means that this draft does not correspond to Softwire charter item and we discover this quite late in the process. My recommendation to the chairs is to read and double check the draft before making an adoption call, especially if there is choice. As I mentioned in my mboned mail, in multicast transition I think the right approach is to agree to the fact that most of the host's communication will be unicast. For unicast, v4-v6 transition has already been well analyzed and several protocols have been specified. Multicast extensions to those protocols are what we need. Regards, Behcet ___ 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] WG last call on draft-ietf-softwire-dslite-multicast-02
On 6/10/2012 11:15 PM, mohamed.boucad...@orange.com wrote: Hi Behcet, I failed to understand the point you are trying to make. The current situations is: * this document provides multicast extension to deliver multicast to DS-Lite serviced customers But not only DS-Lite. * we rely on multicast capabilities, as such no AMT-like considerations are included * the proposed solution is generic and can be deployed in any 4-6-4 use case Agree it is generic, and I think the draft should be revised to reflect that. Stig What should be revised? Thanks for your help. Cheers, Med -Message d'origine- De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Envoyé : vendredi 8 juin 2012 17:35 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Wojciech Dec; Stig Venaas; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Hi Med, I agree with Woj. I do not favor moving this draft to somewhere else. Instead this draft should be revised to make it Multicast extensions to DS-Lite as in the charter. There is enough time to do it. Regards, Behcet On Fri, Jun 8, 2012 at 3:43 AM,mohamed.boucad...@orange.com wrote: Hi Woj, Your comment is valid. The point I wanted to make is to recall the initial motivation of this draft: solve an issue raised by DS-Lite people. Evidently, the proposed approach can be deployed in any 4-6-4 scenario. This will be reflected in the updated version of the draft. Cheers, Med De : Wojciech Dec [mailto:wdec.i...@gmail.com] Envoyé : vendredi 8 juin 2012 09:57 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : sarik...@ieee.org; Stig Venaas; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Hello Med, there is no dependency here on ds-lite, ie This has all the hallmarks of a standalone solution, which will almost certainly be implemented as such, and one that will work with or without ds-lite for unicast. Regards, Woj. On 8 June 2012 07:48,mohamed.boucad...@orange.com wrote: Re-, May I re-iterate: * The draft is designed to allow the delivery of multicast services to DS-Lite serviced customers. * The draft proposes multicast extensions and not unicast ones. Cheers, Med -Message d'origine- De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Envoyé : jeudi 7 juin 2012 20:20 À : Stig Venaas Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 On Thu, Jun 7, 2012 at 12:48 PM, Stig Venaas s...@venaas.com wrote: On 6/7/2012 10:08 AM, Behcet Sarikaya wrote: On Thu, Jun 7, 2012 at 8:07 AM,mohamed.boucad...@orange.comwrote: So you are saying that this draft does not correspond to Multicast extensions for DS-Lite? I sent a separate review, but anyway, it is not an extension to DS-Lite as I see it. It is a completely generic approach for tunneling v6 through v4. It can certainly be deployed in DS-Lite scenarios, but it is much more generic. I would like the title and the text to reflect that. So it means that this draft does not correspond to Softwire charter item and we discover this quite late in the process. My recommendation to the chairs is to read and double check the draft before making an adoption call, especially if there is choice. As I mentioned in my mboned mail, in multicast transition I think the right approach is to agree to the fact that most of the host's communication will be unicast. For unicast, v4-v6 transition has already been well analyzed and several protocols have been specified. Multicast extensions to those protocols are what we need. Regards, Behcet ___ 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] WG last call on draft-ietf-softwire-dslite-multicast-02
On 6/11/2012 1:21 PM, Tina TSOU wrote: If we r looking for a generic encapsulation for multicast transition, here it is. http://datatracker.ietf.org/doc/draft-tsou-softwire-encapsulated-multicast/ In a way, your draft is even more generic Tina. There are also some differences. You're talking about a stateful mapping function and a protocol for requesting mappings. This is avoided here by using a stateless mapping. But roughly speaking, I think your general description Tina, may also include what this draft does. Stig Tina 408-859-4996 On Jun 11, 2012, at 12:08 PM, Stig Venaass...@venaas.com wrote: On 6/10/2012 11:15 PM, mohamed.boucad...@orange.com wrote: Hi Behcet, I failed to understand the point you are trying to make. The current situations is: * this document provides multicast extension to deliver multicast to DS-Lite serviced customers But not only DS-Lite. * we rely on multicast capabilities, as such no AMT-like considerations are included * the proposed solution is generic and can be deployed in any 4-6-4 use case Agree it is generic, and I think the draft should be revised to reflect that. Stig What should be revised? Thanks for your help. Cheers, Med -Message d'origine- De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Envoyé : vendredi 8 juin 2012 17:35 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Wojciech Dec; Stig Venaas; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Hi Med, I agree with Woj. I do not favor moving this draft to somewhere else. Instead this draft should be revised to make it Multicast extensions to DS-Lite as in the charter. There is enough time to do it. Regards, Behcet On Fri, Jun 8, 2012 at 3:43 AM,mohamed.boucad...@orange.com wrote: Hi Woj, Your comment is valid. The point I wanted to make is to recall the initial motivation of this draft: solve an issue raised by DS-Lite people. Evidently, the proposed approach can be deployed in any 4-6-4 scenario. This will be reflected in the updated version of the draft. Cheers, Med De : Wojciech Dec [mailto:wdec.i...@gmail.com] Envoyé : vendredi 8 juin 2012 09:57 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : sarik...@ieee.org; Stig Venaas; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Hello Med, there is no dependency here on ds-lite, ie This has all the hallmarks of a standalone solution, which will almost certainly be implemented as such, and one that will work with or without ds-lite for unicast. Regards, Woj. On 8 June 2012 07:48,mohamed.boucad...@orange.com wrote: Re-, May I re-iterate: * The draft is designed to allow the delivery of multicast services to DS-Lite serviced customers. * The draft proposes multicast extensions and not unicast ones. Cheers, Med -Message d'origine- De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Envoyé : jeudi 7 juin 2012 20:20 À : Stig Venaas Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 On Thu, Jun 7, 2012 at 12:48 PM, Stig Venaas s...@venaas.com wrote: On 6/7/2012 10:08 AM, Behcet Sarikaya wrote: On Thu, Jun 7, 2012 at 8:07 AM,mohamed.boucad...@orange.com wrote: So you are saying that this draft does not correspond to Multicast extensions for DS-Lite? I sent a separate review, but anyway, it is not an extension to DS-Lite as I see it. It is a completely generic approach for tunneling v6 through v4. It can certainly be deployed in DS-Lite scenarios, but it is much more generic. I would like the title and the text to reflect that. So it means that this draft does not correspond to Softwire charter item and we discover this quite late in the process. My recommendation to the chairs is to read and double check the draft before making an adoption call, especially if there is choice. As I mentioned in my mboned mail, in multicast transition I think the right approach is to agree to the fact that most of the host's communication will be unicast. For unicast, v4-v6 transition has already been well analyzed and several protocols have been specified. Multicast extensions to those protocols are what we need. Regards, Behcet ___ 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] WG last call on draft-ietf-softwire-dslite-multicast-02
Hi Woj, Your comment is valid. The point I wanted to make is to recall the initial motivation of this draft: solve an issue raised by DS-Lite people. Evidently, the proposed approach can be deployed in any 4-6-4 scenario. This will be reflected in the updated version of the draft. Cheers, Med De : Wojciech Dec [mailto:wdec.i...@gmail.com] Envoyé : vendredi 8 juin 2012 09:57 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : sarik...@ieee.org; Stig Venaas; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Hello Med, there is no dependency here on ds-lite, ie This has all the hallmarks of a standalone solution, which will almost certainly be implemented as such, and one that will work with or without ds-lite for unicast. Regards, Woj. On 8 June 2012 07:48, mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com wrote: Re-, May I re-iterate: * The draft is designed to allow the delivery of multicast services to DS-Lite serviced customers. * The draft proposes multicast extensions and not unicast ones. Cheers, Med -Message d'origine- De : Behcet Sarikaya [mailto:sarikaya2...@gmail.commailto:sarikaya2...@gmail.com] Envoyé : jeudi 7 juin 2012 20:20 À : Stig Venaas Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; softwires@ietf.orgmailto:softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 On Thu, Jun 7, 2012 at 12:48 PM, Stig Venaas s...@venaas.commailto:s...@venaas.com wrote: On 6/7/2012 10:08 AM, Behcet Sarikaya wrote: On Thu, Jun 7, 2012 at 8:07 AM,mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com wrote: So you are saying that this draft does not correspond to Multicast extensions for DS-Lite? I sent a separate review, but anyway, it is not an extension to DS-Lite as I see it. It is a completely generic approach for tunneling v6 through v4. It can certainly be deployed in DS-Lite scenarios, but it is much more generic. I would like the title and the text to reflect that. So it means that this draft does not correspond to Softwire charter item and we discover this quite late in the process. My recommendation to the chairs is to read and double check the draft before making an adoption call, especially if there is choice. As I mentioned in my mboned mail, in multicast transition I think the right approach is to agree to the fact that most of the host's communication will be unicast. For unicast, v4-v6 transition has already been well analyzed and several protocols have been specified. Multicast extensions to those protocols are what we need. Regards, Behcet ___ 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] WG last call on draft-ietf-softwire-dslite-multicast-02
Re-,
On 6/5/2012 Tuesday 9:09 PM, Simon Perreault wrote:
On 2012-06-04 22:13, Jacni Qin wrote:
Section 6.1 introduces IGMP/MLD translation, but I fear it is very
underspecified. Our own effort at specifying IGMP/MLD translation is
in draft-perreault-mboned-igmp-mld-translation. I feel that DS-Lite
multicast would be better served by referencing our draft instead.
Thanks for your comments, while as stated in the text, the Interworking
function is a combination of proxying (RFC4605) and translation
(draft-ietf-mboned-64-multicast-address-format, sorry the reference was
lost, we'll fix it).
I understand that. But note that this is an important new function.
AFAIK IGMP/MLD translation doesn't exist in any other RFC. Your draft
would be underspecifying it IMHO, possibly leading to interoperability
issues.
To be honest, we've ever considered a separate draft to specify that
function, but we finally dropped it in the last moment before
submitting, since we realized during the preparation for the Demo in
Taipei that it's actually not a new function, nor needs to be
standardized anywhere, but more belongs to the scope of implementation.
The implements vary, one example could be: have both IPv4 and IPv6
membership database maintained, then just synchronize the two through
the address translation, all other things can be handled by the Proxying
functionality (RFC4605).
I don't think it's up to SOFTWIRE to standardize IGMP/MLD translation.
The implementations vary, and we are trying to avoid deeply diving into
that since it is sufficient for the implementers, and those should be
detailed in some deployment document if needed. Anyway, please list what
you think is missing, we can add more text to further clarify it. Thanks
a lot!
At IETF 83 I showed this list to the PIM working group to demonstrate
that IGMP/MLD translation is not as simple as people think it is. It's
a list of things our draft
(draft-perreault-mboned-igmp-mld-translation) specifies:
- Well-known multicast address equivalences between IPv4 and IPv6.
- Message type equivalences between IGMPv{1,2,3} and MLDv{1,2}.
- Translation needs to be performed logically on upstream interface of
proxy so as not to mess with Querier elections.
- Router Alert
- IPv4 option ? Hop-by-Hop IPv6 extension header
- Send on output IFF it was received on input.
- Set value to zero unconditionally.
- Reports with unspecified source address need to be handled
differently for IGMP vs MLD.
- Allocation of a Translated bit in IGMPv3 and MLDv2 Queries and
Reports.
- Formulas for the conversion of MRD?MRT with or without loss of
precision.
- Preservation of Additional and Auxiliary Data.
- MTU considerations... sigh
- Data plane handled according to RFC6145.
You are doing a protocol translation, which is just one possible kind of
implementations, and it's true that what you list above are required if
you want to go this way, IMHO it is a complicated one.
As mentioned earlier, RFC4605 plus the address translation can also do
that. And most columns you list will be avoid.
While I'm happy to see a deployment document to discuss the issues of
implementations.
Cheers,
Jacni
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02
Hi Med, I agree with Woj. I do not favor moving this draft to somewhere else. Instead this draft should be revised to make it Multicast extensions to DS-Lite as in the charter. There is enough time to do it. Regards, Behcet On Fri, Jun 8, 2012 at 3:43 AM, mohamed.boucad...@orange.com wrote: Hi Woj, Your comment is valid. The point I wanted to make is to recall the initial motivation of this draft: solve an issue raised by DS-Lite people. Evidently, the proposed approach can be deployed in any 4-6-4 scenario. This will be reflected in the updated version of the draft. Cheers, Med De : Wojciech Dec [mailto:wdec.i...@gmail.com] Envoyé : vendredi 8 juin 2012 09:57 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : sarik...@ieee.org; Stig Venaas; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Hello Med, there is no dependency here on ds-lite, ie This has all the hallmarks of a standalone solution, which will almost certainly be implemented as such, and one that will work with or without ds-lite for unicast. Regards, Woj. On 8 June 2012 07:48, mohamed.boucad...@orange.com wrote: Re-, May I re-iterate: * The draft is designed to allow the delivery of multicast services to DS-Lite serviced customers. * The draft proposes multicast extensions and not unicast ones. Cheers, Med -Message d'origine- De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Envoyé : jeudi 7 juin 2012 20:20 À : Stig Venaas Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 On Thu, Jun 7, 2012 at 12:48 PM, Stig Venaas s...@venaas.com wrote: On 6/7/2012 10:08 AM, Behcet Sarikaya wrote: On Thu, Jun 7, 2012 at 8:07 AM,mohamed.boucad...@orange.com wrote: So you are saying that this draft does not correspond to Multicast extensions for DS-Lite? I sent a separate review, but anyway, it is not an extension to DS-Lite as I see it. It is a completely generic approach for tunneling v6 through v4. It can certainly be deployed in DS-Lite scenarios, but it is much more generic. I would like the title and the text to reflect that. So it means that this draft does not correspond to Softwire charter item and we discover this quite late in the process. My recommendation to the chairs is to read and double check the draft before making an adoption call, especially if there is choice. As I mentioned in my mboned mail, in multicast transition I think the right approach is to agree to the fact that most of the host's communication will be unicast. For unicast, v4-v6 transition has already been well analyzed and several protocols have been specified. Multicast extensions to those protocols are what we need. Regards, Behcet ___ 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] WG last call on draft-ietf-softwire-dslite-multicast-02
On 6/8/2012 8:34 AM, Behcet Sarikaya wrote: Hi Med, I agree with Woj. I do not favor moving this draft to somewhere else. Instead this draft should be revised to make it Multicast extensions to DS-Lite as in the charter. There is enough time to do it. As this draft shows though, one can provide multicast in a DS-Lite environment in an entirely generic way. I think that is great. It's much better to have a general solution. But this means the draft should be modified to reflect that. It is great to have a draft describing this. Whether charter or not or where it belongs is something I'm sure can be figured out. Right now I'm more concerned about getting a good document. Stig Regards, Behcet On Fri, Jun 8, 2012 at 3:43 AM,mohamed.boucad...@orange.com wrote: Hi Woj, Your comment is valid. The point I wanted to make is to recall the initial motivation of this draft: solve an issue raised by DS-Lite people. Evidently, the proposed approach can be deployed in any 4-6-4 scenario. This will be reflected in the updated version of the draft. Cheers, Med De : Wojciech Dec [mailto:wdec.i...@gmail.com] Envoyé : vendredi 8 juin 2012 09:57 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : sarik...@ieee.org; Stig Venaas; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Hello Med, there is no dependency here on ds-lite, ie This has all the hallmarks of a standalone solution, which will almost certainly be implemented as such, and one that will work with or without ds-lite for unicast. Regards, Woj. On 8 June 2012 07:48,mohamed.boucad...@orange.com wrote: Re-, May I re-iterate: * The draft is designed to allow the delivery of multicast services to DS-Lite serviced customers. * The draft proposes multicast extensions and not unicast ones. Cheers, Med -Message d'origine- De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Envoyé : jeudi 7 juin 2012 20:20 À : Stig Venaas Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 On Thu, Jun 7, 2012 at 12:48 PM, Stig Venaass...@venaas.com wrote: On 6/7/2012 10:08 AM, Behcet Sarikaya wrote: On Thu, Jun 7, 2012 at 8:07 AM,mohamed.boucad...@orange.comwrote: So you are saying that this draft does not correspond to Multicast extensions for DS-Lite? I sent a separate review, but anyway, it is not an extension to DS-Lite as I see it. It is a completely generic approach for tunneling v6 through v4. It can certainly be deployed in DS-Lite scenarios, but it is much more generic. I would like the title and the text to reflect that. So it means that this draft does not correspond to Softwire charter item and we discover this quite late in the process. My recommendation to the chairs is to read and double check the draft before making an adoption call, especially if there is choice. As I mentioned in my mboned mail, in multicast transition I think the right approach is to agree to the fact that most of the host's communication will be unicast. For unicast, v4-v6 transition has already been well analyzed and several protocols have been specified. Multicast extensions to those protocols are what we need. Regards, Behcet ___ 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] WG last call on draft-ietf-softwire-dslite-multicast-02
On Fri, Jun 8, 2012 at 11:58 AM, Stig Venaas s...@venaas.com wrote: On 6/8/2012 8:34 AM, Behcet Sarikaya wrote: Hi Med, I agree with Woj. I do not favor moving this draft to somewhere else. Instead this draft should be revised to make it Multicast extensions to DS-Lite as in the charter. There is enough time to do it. As this draft shows though, one can provide multicast in a DS-Lite environment in an entirely generic way. I think that is great. It's much better to have a general solution. But this means the draft should be modified to reflect that. It is great to have a draft describing this. A general solution using translation won't simply cut it for DS-Lite which is a tunneling protocol. No matter how hard you try. Behcet ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02
Hi Simon, We tried in this document to avoid as much as possible including implementation details but instead we focused on the external behaviour of the interworking functions. Let me recall there are already available implementations based on the specification of draft-ietf-softwire-dslite-multicast. A demo has been organized in one of the previous IETF meetings. Now for your comment, we can see the IGMP/MLD IWF is basically RFC4605 + address translation (draft-ietf-mboned-64-multicast-address-format). Among the use cases of high priority identified in http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00#section-3.6, the IGMP/MLD IWF is only required for the use case described in draft-ietf-softwire-dslite-multicast. As such, does-it really make sense to have a dedicated document for the IGMP/MLD IWF? Wouldn't be efficient to have this elaborated in draft-ietf-softwire-dslite-multicast? I personally vote for the second option. Of course, if this approach is maintained, the document should be LCed also in PIM and MBONED. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Simon Perreault Envoyé : lundi 28 mai 2012 16:11 À : Yong Cui Cc : softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 On 2012-05-27 10:34, Yong Cui wrote: This is a wg last call on draft-ietf-softwire-dslite-multicast-02. Section 6.1 introduces IGMP/MLD translation, but I fear it is very underspecified. Our own effort at specifying IGMP/MLD translation is in draft-perreault-mboned-igmp-mld-translation. I feel that DS-Lite multicast would be better served by referencing our draft instead. So I would suggest replacing section 6.1 by a reference to the draft above, which we hope to have adopted in the PIM WG shortly. Thanks, Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca ___ 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] WG last call on draft-ietf-softwire-dslite-multicast-02
On 2012-06-07 08:51, mohamed.boucad...@orange.com wrote: Among the use cases of high priority identified in http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00#section-3.6, the IGMP/MLD IWF is only required for the use case described in draft-ietf-softwire-dslite-multicast. The DS-Lite case is one instance of the 4-6-4 use case where encapsulation is used. Another instance of the 4-6-4 use case makes use of translation instead. That is not covered by the softwire draft. The 6-4-6-4 use case is also high priority, requires IGMP/MLD translation, and is not covered by the softwire draft. So we're looking at at least three use cases of IGMP/MLD translation, possibly more, of which only one is covered by the softwire draft. As such, does-it really make sense to have a dedicated document for the IGMP/MLD IWF? Wouldn't be efficient to have this elaborated in draft-ietf-softwire-dslite-multicast? I personally vote for the second option. Of course, if this approach is maintained, the document should be LCed also in PIM and MBONED. I think IGMP/MLD translation should stand on its own for the reasons above, and it should be a PIM document. Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02
Re-, See inline. Cheers, Med -Message d'origine- De : Simon Perreault [mailto:simon.perrea...@viagenie.ca] Envoyé : jeudi 7 juin 2012 15:47 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Yong Cui; softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 On 2012-06-07 08:51, mohamed.boucad...@orange.com wrote: Among the use cases of high priority identified in http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00#s ection-3.6, the IGMP/MLD IWF is only required for the use case described in draft-ietf-softwire-dslite-multicast. The DS-Lite case is one instance of the 4-6-4 use case where encapsulation is used. Another instance of the 4-6-4 use case makes use of translation instead. That is not covered by the softwire draft. Med: It was there; see http://tools.ietf.org/html/draft-ietf-softwire-dslite-multicast-00#appendix-A.1. I failed to find back why we removed it in -01 of the draft. BTW, this is not a diffrent use case, only the way data is handled differs. The 6-4-6-4 use case is also high priority, requires IGMP/MLD translation, and is not covered by the softwire draft. Med: I'm not sure there is a consenus about the urgency of 6-4-6-4 scenario. I knwo there is an operator representative voicing for it, but I always failed to understand that use case. So we're looking at at least three use cases of IGMP/MLD translation, possibly more, of which only one is covered by the softwire draft. Med: I failed to count the three use cases.. As such, does-it really make sense to have a dedicated document for the IGMP/MLD IWF? Wouldn't be efficient to have this elaborated in draft-ietf-softwire-dslite-multicast? I personally vote for the second option. Of course, if this approach is maintained, the document should be LCed also in PIM and MBONED. I think IGMP/MLD translation should stand on its own for the reasons above, and it should be a PIM document. Med: There is no PIM WG document to cite at this stage. What is wrong with LCing this in PIM and MBONED? ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02
On Thu, Jun 7, 2012 at 8:07 AM, mohamed.boucad...@orange.com wrote: Hi Woj, DS-Lite terminology is used in the sense that an IPv4 receiver is delivered (IPv4) multicast content (from an IPv4 source) over an IPv6 network. The generic use case as described in http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00#section-3.1 is called 4-6-4. I personally agree to change the title to reflect this. The document does not make any assumption about the location of AFTR and mAFTR: deployment considerations are out of scope. FWIW, mAFTR is defined as follows: o Multicast AFTR (mAFTR): is a functional entity which supports IPv4-IPv6 multicast interworking function (refer to Figure 3). It receives and encapsulates the IPv4 multicast packets into IPv4-in- IPv6 packets and behaves as the corresponding IPv6 multicast source for the encapsulated IPv4-in-IPv6 packets. If you still think mAFTR terminology is confusing, we can change it to mBR (for multicast Border Router), 64mBR (IPv6/IPv4 Multicast Border Router), mIXF (multicast Interconnection Function), etc. So you are saying that this draft does not correspond to Multicast extensions for DS-Lite? Behcet ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02
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. 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. 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. 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. 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. 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. 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. The draft assumes PIM-SM is used. I think the approach could also be used with e.g. PIM Bidir (RFC 5015). 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. 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? 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
Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02
On Thu, Jun 7, 2012 at 12:48 PM, Stig Venaas s...@venaas.com wrote: On 6/7/2012 10:08 AM, Behcet Sarikaya wrote: On Thu, Jun 7, 2012 at 8:07 AM,mohamed.boucad...@orange.com wrote: So you are saying that this draft does not correspond to Multicast extensions for DS-Lite? I sent a separate review, but anyway, it is not an extension to DS-Lite as I see it. It is a completely generic approach for tunneling v6 through v4. It can certainly be deployed in DS-Lite scenarios, but it is much more generic. I would like the title and the text to reflect that. So it means that this draft does not correspond to Softwire charter item and we discover this quite late in the process. My recommendation to the chairs is to read and double check the draft before making an adoption call, especially if there is choice. As I mentioned in my mboned mail, in multicast transition I think the right approach is to agree to the fact that most of the host's communication will be unicast. For unicast, v4-v6 transition has already been well analyzed and several protocols have been specified. Multicast extensions to those protocols are what we need. Regards, Behcet ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02
+1
The IGMP/MLD translation is the key piece of this draft and needs to be
thorough.
In addition a general observation: This draft appears to have very little
in common with DS-Lite (nothing except use of IPinIP on my reading), and
using that reference and the AFTR terms is confusing. The fact that
technically it features an address family mapped multicast transport, which
alongside with the IGMP/MLD translation makes it anything but transparent
tunneling. A change of title would be also useful, as well as general
decoupling from the ds-lite architecture: The mAFTR device can, and likely
will be a often a dedicated multicast device that plays no part in unicast
forwarding.
-Woj.
On 5 June 2012 15:09, Simon Perreault simon.perrea...@viagenie.ca wrote:
On 2012-06-04 22:13, Jacni Qin wrote:
Section 6.1 introduces IGMP/MLD translation, but I fear it is very
underspecified. Our own effort at specifying IGMP/MLD translation is
in draft-perreault-mboned-igmp-**mld-translation. I feel that DS-Lite
multicast would be better served by referencing our draft instead.
Thanks for your comments, while as stated in the text, the Interworking
function is a combination of proxying (RFC4605) and translation
(draft-ietf-mboned-64-**multicast-address-format, sorry the reference was
lost, we'll fix it).
I understand that. But note that this is an important new function. AFAIK
IGMP/MLD translation doesn't exist in any other RFC. Your draft would be
underspecifying it IMHO, possibly leading to interoperability issues.
I don't think it's up to SOFTWIRE to standardize IGMP/MLD translation.
The implementations vary, and we are trying to avoid deeply diving into
that since it is sufficient for the implementers, and those should be
detailed in some deployment document if needed. Anyway, please list what
you think is missing, we can add more text to further clarify it. Thanks
a lot!
At IETF 83 I showed this list to the PIM working group to demonstrate that
IGMP/MLD translation is not as simple as people think it is. It's a list of
things our draft (draft-perreault-mboned-igmp-**mld-translation)
specifies:
- Well-known multicast address equivalences between IPv4 and IPv6.
- Message type equivalences between IGMPv{1,2,3} and MLDv{1,2}.
- Translation needs to be performed logically on upstream interface of
proxy so as not to mess with Querier elections.
- Router Alert
- IPv4 option ↔ Hop-by-Hop IPv6 extension header
- Send on output IFF it was received on input.
- Set value to zero unconditionally.
- Reports with unspecified source address need to be handled differently
for IGMP vs MLD.
- Allocation of a “Translated” bit in IGMPv3 and MLDv2 Queries and Reports.
- Formulas for the conversion of MRD↔MRT with or without loss of precision.
- Preservation of Additional and Auxiliary Data.
- MTU considerations... sigh
- Data plane handled according to RFC6145.
I don't want to argue this list in SOFTWIRE because I think it's the wrong
forum. My point is that IGMP/MLD translation needs to be correctly
specified, and it needs to be done in PIM. Any SOFTWIRE protocol that
requires IGMP/MLD translation needs to refer to something coming from PIM.
Simon
--
DTN made easy, lean, and smart --
http://postellation.viagenie.**cahttp://postellation.viagenie.ca
NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca
STUN/TURN server -- http://numb.viagenie.ca
__**_
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/**listinfo/softwireshttps://www.ietf.org/mailman/listinfo/softwires
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02
On Wed, Jun 6, 2012 at 8:43 AM, Wojciech Dec wdec.i...@gmail.com wrote: +1 The IGMP/MLD translation is the key piece of this draft and needs to be thorough. In addition a general observation: This draft appears to have very little in common with DS-Lite (nothing except use of IPinIP on my reading), and using that reference and the AFTR terms is confusing. The fact that technically it features an address family mapped multicast transport, which alongside with the IGMP/MLD translation makes it anything but transparent tunneling. A change of title would be also useful, as well as general decoupling from the ds-lite architecture: The mAFTR device can, and likely will be a often a dedicated multicast device that plays no part in unicast forwarding. You mean, in order to be DS-Lite related it has to be tunneling based? Actually, I did have a draft with such a solution. Some people argued that we should not go for a tunneling solution because there is already an inherent tunneling. So this draft was chosen as the solution approach. The philosophical question here is why do we have DS-Lite which does tunneling on top of the inherent tunnel? Behcet ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02
On 2012-06-04 22:13, Jacni Qin wrote:
Section 6.1 introduces IGMP/MLD translation, but I fear it is very
underspecified. Our own effort at specifying IGMP/MLD translation is
in draft-perreault-mboned-igmp-mld-translation. I feel that DS-Lite
multicast would be better served by referencing our draft instead.
Thanks for your comments, while as stated in the text, the Interworking
function is a combination of proxying (RFC4605) and translation
(draft-ietf-mboned-64-multicast-address-format, sorry the reference was
lost, we'll fix it).
I understand that. But note that this is an important new function.
AFAIK IGMP/MLD translation doesn't exist in any other RFC. Your draft
would be underspecifying it IMHO, possibly leading to interoperability
issues.
I don't think it's up to SOFTWIRE to standardize IGMP/MLD translation.
The implementations vary, and we are trying to avoid deeply diving into
that since it is sufficient for the implementers, and those should be
detailed in some deployment document if needed. Anyway, please list what
you think is missing, we can add more text to further clarify it. Thanks
a lot!
At IETF 83 I showed this list to the PIM working group to demonstrate
that IGMP/MLD translation is not as simple as people think it is. It's a
list of things our draft (draft-perreault-mboned-igmp-mld-translation)
specifies:
- Well-known multicast address equivalences between IPv4 and IPv6.
- Message type equivalences between IGMPv{1,2,3} and MLDv{1,2}.
- Translation needs to be performed logically on upstream interface of
proxy so as not to mess with Querier elections.
- Router Alert
- IPv4 option ↔ Hop-by-Hop IPv6 extension header
- Send on output IFF it was received on input.
- Set value to zero unconditionally.
- Reports with unspecified source address need to be handled differently
for IGMP vs MLD.
- Allocation of a “Translated” bit in IGMPv3 and MLDv2 Queries and Reports.
- Formulas for the conversion of MRD↔MRT with or without loss of precision.
- Preservation of Additional and Auxiliary Data.
- MTU considerations... sigh
- Data plane handled according to RFC6145.
I don't want to argue this list in SOFTWIRE because I think it's the
wrong forum. My point is that IGMP/MLD translation needs to be correctly
specified, and it needs to be done in PIM. Any SOFTWIRE protocol that
requires IGMP/MLD translation needs to refer to something coming from PIM.
Simon
--
DTN made easy, lean, and smart -- http://postellation.viagenie.ca
NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca
STUN/TURN server -- http://numb.viagenie.ca
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02
hi simon, Sorry for the late reply, please see below, On 5/28/2012 Monday 10:11 PM, Simon Perreault wrote: On 2012-05-27 10:34, Yong Cui wrote: This is a wg last call on draft-ietf-softwire-dslite-multicast-02. Section 6.1 introduces IGMP/MLD translation, but I fear it is very underspecified. Our own effort at specifying IGMP/MLD translation is in draft-perreault-mboned-igmp-mld-translation. I feel that DS-Lite multicast would be better served by referencing our draft instead. Thanks for your comments, while as stated in the text, the Interworking function is a combination of proxying (RFC4605) and translation (draft-ietf-mboned-64-multicast-address-format, sorry the reference was lost, we'll fix it). The implementations vary, and we are trying to avoid deeply diving into that since it is sufficient for the implementers, and those should be detailed in some deployment document if needed. Anyway, please list what you think is missing, we can add more text to further clarify it. Thanks a lot! Cheers, Jacni So I would suggest replacing section 6.1 by a reference to the draft above, which we hope to have adopted in the PIM WG shortly. Thanks, Simon ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02
On 2012-05-27 10:34, Yong Cui wrote: This is a wg last call on draft-ietf-softwire-dslite-multicast-02. Section 6.1 introduces IGMP/MLD translation, but I fear it is very underspecified. Our own effort at specifying IGMP/MLD translation is in draft-perreault-mboned-igmp-mld-translation. I feel that DS-Lite multicast would be better served by referencing our draft instead. So I would suggest replacing section 6.1 by a reference to the draft above, which we hope to have adopted in the PIM WG shortly. Thanks, Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02
Hi folks, This is a wg last call on draft-ietf-softwire-dslite-multicast-02. http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-multicast/ As usual, please send editorial comments to the authors and substantive comments to the mailing list. This wg last call will end on June 10 at 12pm EDT. Yong Alain ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
