Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01
Qiong, If public 4over6 is one extreme case of MAP, in which one subscriber represents one MAP domain, then should we also say that DS-Lite is another extreme case of MAP, where one application (session) represents one MAP domain ? a DS-lite AFTR could be represented by the combination of a MAP BR with per subscriber rules combined with a NAT44. there is a reason we started out calling MAP for Stateless DS-lite. I think we should still keep the initial feature of these solutions. all the proposed solutions, including DS-lite shares a large set of commonalities. where the differences are more operational considerations and deployment choices than technical differences. do we need a separate protocol specification for each deployment choice? cheers, Ole ___ 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-public-4over6-01
Med, From protocol level, the difference between public 4over6 and lightweight 4over6(b4-translated-ds-lite) lies in port-set support. The extra efforts of lw 4over6 are as follows: (1) port set support in DHCP provisioning; (2) NAT on the initiator side.(whose address pool is not a full address but only a port set) (3) port-set supporting in the cocentrator's binding table. While we may cover public 4over6 by lightweight 4over6 with a special port set format (2^16 size) for (3), (1) and (2) brings quite significant changes to the intiator side. If I'm only a pb 4over6 initiator, more typically a host initiator, all the complexity needed is to plant a CRA process on the host, which is basically an IPv4 IPv6 socket function, to support DHCPv4-over-IPv6. The rest is already there: we don't need to modify DHCP client, and IPv4-in-IPv6 tunnel is already supported in today's OS. No NAT is needed in host case, and full e2e transparency is guaranteed. If we support this by lw 4over6, we implemented extra complexity which is not needed at all by the initiator. We have deployement scenarios which probably don't require address sharing, such as CERNET, and I guess maybe the ISPs in USA also do not have an IPv4 address shortage problem? So, aside from the fact that the pb 4over6 draft starts earlier and its status has been a step furher, this is a problem of choice: do we want two clean, simple mechanisms, or one mechanism trying to be compatible with both. On Thu, Jun 7, 2012 at 9:11 PM, mohamed.boucad...@orange.com wrote: Dear all, I agree with Reinaldo. IMHO it makes sense to merge the two documents: either draft-ietf-softwire-public-4over6 be extended to cover draft-cui-softwire-b4-translated-ds-lite or add one or two sentences to draft-cui-softwire-b4-translated-ds-lite to mention a non-shared IPv4 address may be assigned. Doing so would help to rationalize the solution space and associated documents. We have the following main flavours: (1) Full stateful mode: DS-Lite (2) Full stateless mode: MAP (3) Per-customer state/binding mode: lw4o6 (draft-cui-softwire-b4-translated-ds-lite) All the three modes must support the ability to assign a full IPv4 address. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Reinaldo Penno Envoyé : lundi 28 mai 2012 07:53 À : Sheng Jiang; Yong Cui; softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 -1 In which significant way this document is different from http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds- lite-06 ? We can insert one paragraph in the above draft and allow public IPs since NAT is optional. The two documents even use DHCPv4ov6 as provisioning. On 5/27/12 6:32 PM, Sheng Jiang jiangsh...@huawei.com wrote: The document looks mature for being advanced. Sheng Jiang -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Yong Cui Sent: Sunday, May 27, 2012 10:31 PM To: softwires@ietf.org Cc: Yong Cui Subject: [Softwires] WG last call on draft-ietf-softwire-public-4over6- 01 Hi folks, This is a wg last call on draft-ietf-softwire-public-4over6-01. http://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6/ As usual, please send editorial comments to the authors and substantive comments to the mailing list. This wg last call will end on 2012 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 ___ 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 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-public-4over6-01
Qiong, all, Le 2012-06-07 à 16:23, Qiong a écrit : Hi Ole, On Thu, Jun 7, 2012 at 4:48 PM, Ole Trøan otr...@employees.org wrote: I think we should still keep the initial feature of these solutions. all the proposed solutions, including DS-lite shares a large set of commonalities. where the differences are more operational considerations and deployment choices than technical differences. do we need a separate protocol specification for each deployment choice? I vote for describing the protocol specifications for different scenarios seperately. +1 Also considering that: - Draft-ietf-softwire-public-4over6-01 has already reached a WG document status, and needs AFAIK no technical change to become an RFC - It has no dependency on 4rd or MAP - There is even one more solution with different scope but commonality, namely 464XLAT currently discussed in v6ops Regards, RD Although they have some commonalities, there are still quite a lot of differences from techincal details for their own features. As we currently have three categories of solutions, I think it will be easier and clearer for readers to understand each solution in seperated document. Best wishes Qiong cheers, Ole ___ 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
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-public-4over6-01
Hi Peng, I vote for having one single document which covers both shared and full IPv4 address. If you start for instance from draft-cui-softwire-b4-translated-ds-lite, what is needed is to add one sentence to say a full IPv4 address can be provisioned. Does this make draft-cui-softwire-b4-translated-ds-lite more complex? I don't think so. I really think we need all to do an effort of rationalizing the solutions space. Cheers, Med -Message d'origine- De : Peng Wu [mailto:pengwu@gmail.com] Envoyé : jeudi 7 juin 2012 18:31 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Yong Cui; softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 Med, From protocol level, the difference between public 4over6 and lightweight 4over6(b4-translated-ds-lite) lies in port-set support. The extra efforts of lw 4over6 are as follows: (1) port set support in DHCP provisioning; (2) NAT on the initiator side.(whose address pool is not a full address but only a port set) (3) port-set supporting in the cocentrator's binding table. While we may cover public 4over6 by lightweight 4over6 with a special port set format (2^16 size) for (3), (1) and (2) brings quite significant changes to the intiator side. If I'm only a pb 4over6 initiator, more typically a host initiator, all the complexity needed is to plant a CRA process on the host, which is basically an IPv4 IPv6 socket function, to support DHCPv4-over-IPv6. The rest is already there: we don't need to modify DHCP client, and IPv4-in-IPv6 tunnel is already supported in today's OS. No NAT is needed in host case, and full e2e transparency is guaranteed. If we support this by lw 4over6, we implemented extra complexity which is not needed at all by the initiator. We have deployement scenarios which probably don't require address sharing, such as CERNET, and I guess maybe the ISPs in USA also do not have an IPv4 address shortage problem? So, aside from the fact that the pb 4over6 draft starts earlier and its status has been a step furher, this is a problem of choice: do we want two clean, simple mechanisms, or one mechanism trying to be compatible with both. On Thu, Jun 7, 2012 at 9:11 PM, mohamed.boucad...@orange.com wrote: Dear all, I agree with Reinaldo. IMHO it makes sense to merge the two documents: either draft-ietf-softwire-public-4over6 be extended to cover draft-cui-softwire-b4-translated-ds-lite or add one or two sentences to draft-cui-softwire-b4-translated-ds-lite to mention a non-shared IPv4 address may be assigned. Doing so would help to rationalize the solution space and associated documents. We have the following main flavours: (1) Full stateful mode: DS-Lite (2) Full stateless mode: MAP (3) Per-customer state/binding mode: lw4o6 (draft-cui-softwire-b4-translated-ds-lite) All the three modes must support the ability to assign a full IPv4 address. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Reinaldo Penno Envoyé : lundi 28 mai 2012 07:53 À : Sheng Jiang; Yong Cui; softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 -1 In which significant way this document is different from http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds- lite-06 ? We can insert one paragraph in the above draft and allow public IPs since NAT is optional. The two documents even use DHCPv4ov6 as provisioning. On 5/27/12 6:32 PM, Sheng Jiang jiangsh...@huawei.com wrote: The document looks mature for being advanced. Sheng Jiang -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Yong Cui Sent: Sunday, May 27, 2012 10:31 PM To: softwires@ietf.org Cc: Yong Cui Subject: [Softwires] WG last call on draft-ietf-softwire-public-4over6- 01 Hi folks, This is a wg last call on draft-ietf-softwire-public-4over6-01. http://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6/ As usual, please send editorial comments to the authors and substantive comments to the mailing list. This wg last call will end on 2012 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 ___ 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
