Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite
Dear all, I really don't understand this issue. It is even misplaced to have this comment at this stage, since this is a document which has been adopted by the WG and the solution it specifies is the same as the one reviewed by the WG prior to its adoption (i.e., since April 2011). Anyway, below a tentative to explain the overall rationale: DS-Lite model can not be reduced to a CGN/AFTR + tunnel. DS-Lite should be first seen as an IP connectivity service. This service can be defined as follows: * delivery of IPv4 connectivity over an IPv6-capable network. * delivery of native IPv6 connectivity * DS-Lite serviced customers are assigned with IPv6 prefix and no IPv4 address. The unicast portion of the service is defined in RFC6333 and is implemented using a tunnel + CGN. The multicast portion of the service is defined in draft-ietf-softwire-dslite-multicast. This portion of the service can be defined as follows: * delivery of IPv4 multicast content using native IPv6 multicast capabilities * delivery of native IPv6 multicast content The solution proposed in draft-ietf-softwire-dslite-multicast is designed to allow DS-Lite serviced customers be delivered IPv4 multicast services. A side note, I agree with Stig and Woj the proposed solution can be generalized to cover any 4-6-4 scenario. This can be done easily by updating the draft (abstract and introduction) to reflect the change of scope of use cases. We didn't had the ambition to define a generic solution when we wrote this draft, we focused mainly on the DS-Lite context. If there is no objection from the WG, we can implement that change. Cheers, Med -Message d'origine- De : softwire issue tracker [mailto:trac+softw...@tools.ietf.org] Envoyé : vendredi 13 juillet 2012 23:55 À : draft-ietf-softwire-dslite-multic...@tools.ietf.org; sarik...@ieee.org Cc : softwires@ietf.org Objet : Re: [softwire] #10: Nothing in common with DS-Lite #10: Nothing in common with DS-Lite Changes (by sarikaya@.): * owner: sarikaya@. = draft-ietf-softwire-dslite-multicast@. -- -+- Reporter: sarikaya@. | Owner: draft-ietf-softwire-dslite- Type: defect | multicast@. Priority: major| Status: new Component: dslite- | Milestone: milestone1 multicast | Version: 2.0 Severity: In WG Last | Resolution: Call | Keywords: tunneling| -+- Ticket URL: http://trac.tools.ietf.org/wg/softwire/trac/ticket/10#comment:1 softwire http://tools.ietf.org/softwire/ ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] map-00: review on the mode 1:1
Med, 2) and 3) both require configuration and as has been amply discussed technically there is no issue with per subscriber rules in 2) or optimization applying to 3). As such, justifying three different solutions out of which two can technically have the same amount of configuration state and are almost the same appears illogical. From another perspective, defining a solution that by definition requires per subscriber configuration state and does not allow its optimization is highly questionable technically. Regards, Woj. On 26 July 2012 16:34, Maoke fib...@gmail.com wrote: 2012/7/26 mohamed.boucad...@orange.com Dear Ole, all, For sure MAP spec can be updated to cover 1:1 mode but this brings more confusion for some people as this contradicts the no state in ISP network paradigm. I personally vote for limiting MAP to its initial scope rather than trying to cover other deployment options. I see three main flavours which justifies having standalone specification documents: (1) Full stateful mode: DS-Lite (2) Full stateless mode: MAP/4rd (3) Per-customer state/binding mode: lw4o6 (draft-cui-softwire-b4-translated-ds-lite) These three flavours have been already sketched in Figure 7 of RFC6346 (see http://tools.ietf.org/html/rfc6346#section-3.3.4). yes. i share this point. thanks, Med, for the clear explanation on the big picture. - maoke Having standalone specifications for each of these flavours helps operators to better target their suitable deployment model without being disturbed with parameters and details not pertinent for their deployment context. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Ole Trøan Envoyé : jeudi 26 juillet 2012 12:23 À : Lee, Yiu Cc : Softwires-wg Objet : Re: [Softwires] map-00: review on the mode 1:1 Yiu, Set EA bits=0 only saves bits in v6 address and decouples v4/v6 address dependency. It doesn't bring any new function compared to embedding full v4 address in the EA-bit. However, the operation models of EA-bit0 or =0 are very different. By the way, this works only for MAP-E. I fail to see why we want to include this in the base spec. what do you say in the spec if EA=0 and provisioned IPv4 prefix length = 32. the spec has to say something about this to be complete. cheers, Ole Thanks, Yiu On 7/25/12 9:45 PM, Satoru Matsushima satoru.matsush...@gmail.com wrote: Hi Yiu, On 2012/07/26, at 4:08, Lee, Yiu wrote: Ole, Where can I get the formal definition of 1:1 mode? My understanding of 1:1 refers to one public IPv4 address per subscriber but you refer very specific to decoupling IPv4 and IPv6 addresses. It doesn't 1:1 in MAP and 4rd context, because embedding full ipv4 address in ea-bits is as a result of prefix allocation operation. Before MAP was accepted as WG item, MAP was proposed to embed IPv4 address information (EA bits 0) in the CE IPv6 address to achieve stateless. No, there was no such definition for EA-bits length restriction. Now there is a new proposal to add a new feature to have the IPv4 information in the BR only. This change requires to provision individual subscriber information to the BR (instead of aggregated information). Benefit are saving bits and breaking v4 and v6 address dependency. There's no change from previous spec, to just clarify MAP, as a stateless solution, could naturally support most granular mapping rule in its nature. Questions to WG: Is it useful feature to be included in MAP? If not, why and alternative? I believe that it does not make sense to restrict EA-len 0 for both MAP and 4rd. It does make sense that you see MAP as framework of solutions which covers specific 1:1 solution by the mapping algorithm. cheers, --satoru Thanks, Yiu On 7/25/12 2:40 PM, Ole Trøan otr...@employees.org wrote: Yiu, I am not asking whether MAP supports 1:1 mode with no EA bits or not. I am asking MAP allows to embed the 32-bit address in the EA bits to achieve 1:1 mode: The EA bits can contain a full or part of an IPv4 prefix or address, and in the shared IPv4 address case contains a Port-Set Identifier (PSID). Why not use this instead? you can do either. embedding a complete IPv4 address and PSID does require a lot of IPv6 space though. e.g. /56 - 32 - 6 = /18 1:1 mode is typically referred to a model where IPv4 and IPv6 addressing are independent. 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 ___ Softwires mailing list
Re: [Softwires] map-00: review on the mode 1:1
On 26 July 2012 16:59, Lee, Yiu yiu_...@cable.comcast.com wrote: Ole, IMHO the WG will need to decide whether EA=0 should be covered at all. If not, then the draft could explicitly mention EA must be 0 and must contain v4 information in the CE address. If the WG decided this needed to be cover, I would recommend to have a new draft to cover it and leave EA=0 undefined in the base draft. What are the technical arguments for making such a decision? Furthermore, given that EA=0 is already covered (eg embedding of full IPv4 address, no address sharing, if not the other case) you appear to be calling out for a remove that part of the spec complicate it case, even though not disputing the use-fullness of the use-case. Seems a sure way to get us from 1 solution to N solutions just for the sake of it. Thanks, Woj. Thanks, Yiu On 7/26/12 6:22 AM, Ole Trøan otr...@employees.org wrote: Yiu, Set EA bits=0 only saves bits in v6 address and decouples v4/v6 address dependency. It doesn't bring any new function compared to embedding full v4 address in the EA-bit. However, the operation models of EA-bit0 or =0 are very different. By the way, this works only for MAP-E. I fail to see why we want to include this in the base spec. what do you say in the spec if EA=0 and provisioned IPv4 prefix length = 32. the spec has to say something about this to be complete. cheers, Ole Thanks, Yiu On 7/25/12 9:45 PM, Satoru Matsushima satoru.matsush...@gmail.com wrote: Hi Yiu, On 2012/07/26, at 4:08, Lee, Yiu wrote: Ole, Where can I get the formal definition of 1:1 mode? My understanding of 1:1 refers to one public IPv4 address per subscriber but you refer very specific to decoupling IPv4 and IPv6 addresses. It doesn't 1:1 in MAP and 4rd context, because embedding full ipv4 address in ea-bits is as a result of prefix allocation operation. Before MAP was accepted as WG item, MAP was proposed to embed IPv4 address information (EA bits 0) in the CE IPv6 address to achieve stateless. No, there was no such definition for EA-bits length restriction. Now there is a new proposal to add a new feature to have the IPv4 information in the BR only. This change requires to provision individual subscriber information to the BR (instead of aggregated information). Benefit are saving bits and breaking v4 and v6 address dependency. There's no change from previous spec, to just clarify MAP, as a stateless solution, could naturally support most granular mapping rule in its nature. Questions to WG: Is it useful feature to be included in MAP? If not, why and alternative? I believe that it does not make sense to restrict EA-len 0 for both MAP and 4rd. It does make sense that you see MAP as framework of solutions which covers specific 1:1 solution by the mapping algorithm. cheers, --satoru Thanks, Yiu On 7/25/12 2:40 PM, Ole Trøan otr...@employees.org wrote: Yiu, I am not asking whether MAP supports 1:1 mode with no EA bits or not. I am asking MAP allows to embed the 32-bit address in the EA bits to achieve 1:1 mode: The EA bits can contain a full or part of an IPv4 prefix or address, and in the shared IPv4 address case contains a Port-Set Identifier (PSID). Why not use this instead? you can do either. embedding a complete IPv4 address and PSID does require a lot of IPv6 space though. e.g. /56 - 32 - 6 = /18 1:1 mode is typically referred to a model where IPv4 and IPv6 addressing are independent. 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 ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] map-00: review on the mode 1:1
Woj, I am confused. You said given that EA=0 is already covered (eg embedding of full IPv4 address, no address sharing, if not the other case). If I read the spec right, this is my understanding: If I want to embed full v4 address in the CE v6 address, the v4 address will be embedded in the EA. If so, how would EA=0? The EA bits encode the CE specific IPv4 address and port information. The EA bits can contain a full or part of an IPv4 prefix or address, and in the shared IPv4 address case contains a Port-Set Identifier (PSID). I prefer one solution vs. N solutions given that the one solution can logically solve all problems and doesn't cause confusion. Consider we agreed on including 1:1 MAP. When an operator deployed it, he had to ask if I want to share v4 addresses, should I put the v4 info in the EA or set EA=0 and provision PSID? It will create unnecessary confusion. Simply put I am not calling out for a remove that part of the spec complicate it case. My position is quite an opposite. I am calling out for not adding confusion to complicate a spec. In the end, it is up to WG to decide. Thanks, Yiu From: Wojciech Dec wdec.i...@gmail.com Date: Friday, July 27, 2012 8:06 AM To: Yiu L. LEE yiu_...@cable.comcast.com Cc: Ole Trøan otr...@employees.org, Softwires-wg softwires@ietf.org Subject: Re: [Softwires] map-00: review on the mode 1:1 On 26 July 2012 16:59, Lee, Yiu yiu_...@cable.comcast.com wrote: Ole, IMHO the WG will need to decide whether EA=0 should be covered at all. If not, then the draft could explicitly mention EA must be 0 and must contain v4 information in the CE address. If the WG decided this needed to be cover, I would recommend to have a new draft to cover it and leave EA=0 undefined in the base draft. What are the technical arguments for making such a decision? Furthermore, given that EA=0 is already covered (eg embedding of full IPv4 address, no address sharing, if not the other case) you appear to be calling out for a remove that part of the spec complicate it case, even though not disputing the use-fullness of the use-case. Seems a sure way to get us from 1 solution to N solutions just for the sake of it. Thanks, Woj. Thanks, Yiu On 7/26/12 6:22 AM, Ole Trøan otr...@employees.org wrote: Yiu, Set EA bits=0 only saves bits in v6 address and decouples v4/v6 address dependency. It doesn't bring any new function compared to embedding full v4 address in the EA-bit. However, the operation models of EA-bit0 or =0 are very different. By the way, this works only for MAP-E. I fail to see why we want to include this in the base spec. what do you say in the spec if EA=0 and provisioned IPv4 prefix length = 32. the spec has to say something about this to be complete. cheers, Ole Thanks, Yiu On 7/25/12 9:45 PM, Satoru Matsushima satoru.matsush...@gmail.com wrote: Hi Yiu, On 2012/07/26, at 4:08, Lee, Yiu wrote: Ole, Where can I get the formal definition of 1:1 mode? My understanding of 1:1 refers to one public IPv4 address per subscriber but you refer very specific to decoupling IPv4 and IPv6 addresses. It doesn't 1:1 in MAP and 4rd context, because embedding full ipv4 address in ea-bits is as a result of prefix allocation operation. Before MAP was accepted as WG item, MAP was proposed to embed IPv4 address information (EA bits 0) in the CE IPv6 address to achieve stateless. No, there was no such definition for EA-bits length restriction. Now there is a new proposal to add a new feature to have the IPv4 information in the BR only. This change requires to provision individual subscriber information to the BR (instead of aggregated information). Benefit are saving bits and breaking v4 and v6 address dependency. There's no change from previous spec, to just clarify MAP, as a stateless solution, could naturally support most granular mapping rule in its nature. Questions to WG: Is it useful feature to be included in MAP? If not, why and alternative? I believe that it does not make sense to restrict EA-len 0 for both MAP and 4rd. It does make sense that you see MAP as framework of solutions which covers specific 1:1 solution by the mapping algorithm. cheers, --satoru Thanks, Yiu On 7/25/12 2:40 PM, Ole Trøan otr...@employees.org wrote: Yiu, I am not asking whether MAP supports 1:1 mode with no EA bits or not. I am asking MAP allows to embed the 32-bit address in the EA bits to achieve 1:1 mode: The EA bits can contain a full or part of an IPv4 prefix or address, and in the shared IPv4 address case contains a Port-Set Identifier (PSID). Why not use this instead? you can do either. embedding a complete IPv4 address and PSID does require a lot of IPv6 space though. e.g. /56 - 32 - 6 = /18 1:1 mode is typically referred to a model where IPv4 and IPv6 addressing are
Re: [Softwires] map-00: review on the mode 1:1
Woj, The argument you are raising applies also for (1) and (3): one can argue this justifies editing an RFC6333-bis to cover the per-subscriber state case ;-) As I mentioned in my first message, MAP can be extended to cover the per-subscriber case at the cost of adding confusion by abandoning the no state in the ISP network paradigm not to mention the incompatibility with the translation mode (part of the MAP suite), etc. IMO, the issue is not technical. It is more a matter of rationalizing the solution space. Having the three deployment options listed below is IMHO a good direction to take by the WG. Cheers, Med De : Wojciech Dec [mailto:wdec.i...@gmail.com] Envoyé : vendredi 27 juillet 2012 14:00 À : Maoke Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; Softwires-wg Objet : Re: [Softwires] map-00: review on the mode 1:1 Med, 2) and 3) both require configuration and as has been amply discussed technically there is no issue with per subscriber rules in 2) or optimization applying to 3). As such, justifying three different solutions out of which two can technically have the same amount of configuration state and are almost the same appears illogical. From another perspective, defining a solution that by definition requires per subscriber configuration state and does not allow its optimization is highly questionable technically. Regards, Woj. On 26 July 2012 16:34, Maoke fib...@gmail.commailto:fib...@gmail.com wrote: 2012/7/26 mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com Dear Ole, all, For sure MAP spec can be updated to cover 1:1 mode but this brings more confusion for some people as this contradicts the no state in ISP network paradigm. I personally vote for limiting MAP to its initial scope rather than trying to cover other deployment options. I see three main flavours which justifies having standalone specification documents: (1) Full stateful mode: DS-Lite (2) Full stateless mode: MAP/4rd (3) Per-customer state/binding mode: lw4o6 (draft-cui-softwire-b4-translated-ds-lite) These three flavours have been already sketched in Figure 7 of RFC6346 (see http://tools.ietf.org/html/rfc6346#section-3.3.4). yes. i share this point. thanks, Med, for the clear explanation on the big picture. - maoke Having standalone specifications for each of these flavours helps operators to better target their suitable deployment model without being disturbed with parameters and details not pertinent for their deployment context. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.orgmailto:softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.orgmailto:softwires-boun...@ietf.org] De la part de Ole Trøan Envoyé : jeudi 26 juillet 2012 12:23 À : Lee, Yiu Cc : Softwires-wg Objet : Re: [Softwires] map-00: review on the mode 1:1 Yiu, Set EA bits=0 only saves bits in v6 address and decouples v4/v6 address dependency. It doesn't bring any new function compared to embedding full v4 address in the EA-bit. However, the operation models of EA-bit0 or =0 are very different. By the way, this works only for MAP-E. I fail to see why we want to include this in the base spec. what do you say in the spec if EA=0 and provisioned IPv4 prefix length = 32. the spec has to say something about this to be complete. cheers, Ole Thanks, Yiu On 7/25/12 9:45 PM, Satoru Matsushima satoru.matsush...@gmail.commailto:satoru.matsush...@gmail.com wrote: Hi Yiu, On 2012/07/26, at 4:08, Lee, Yiu wrote: Ole, Where can I get the formal definition of 1:1 mode? My understanding of 1:1 refers to one public IPv4 address per subscriber but you refer very specific to decoupling IPv4 and IPv6 addresses. It doesn't 1:1 in MAP and 4rd context, because embedding full ipv4 address in ea-bits is as a result of prefix allocation operation. Before MAP was accepted as WG item, MAP was proposed to embed IPv4 address information (EA bits 0) in the CE IPv6 address to achieve stateless. No, there was no such definition for EA-bits length restriction. Now there is a new proposal to add a new feature to have the IPv4 information in the BR only. This change requires to provision individual subscriber information to the BR (instead of aggregated information). Benefit are saving bits and breaking v4 and v6 address dependency. There's no change from previous spec, to just clarify MAP, as a stateless solution, could naturally support most granular mapping rule in its nature. Questions to WG: Is it useful feature to be included in MAP? If not, why and alternative? I believe that it does not make sense to restrict EA-len 0 for both MAP and 4rd. It does make sense that you see MAP as framework of solutions which covers specific 1:1 solution by the mapping algorithm. cheers, --satoru Thanks, Yiu On 7/25/12 2:40 PM, Ole Trøan otr...@employees.orgmailto:otr...@employees.org wrote: Yiu, I am not asking whether MAP
Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite
Med, the point is that the DS-Lite (CGN AFTR) solution is not necessary to be deployed for the multicast solution described here to work. As to how this ended up being charterd in Softwire I don't know and IMO it doesn't make much sense. Regards, Woj. On 27 July 2012 13:48, mohamed.boucad...@orange.com wrote: Dear all, I really don't understand this issue. It is even misplaced to have this comment at this stage, since this is a document which has been adopted by the WG and the solution it specifies is the same as the one reviewed by the WG prior to its adoption (i.e., since April 2011). Anyway, below a tentative to explain the overall rationale: DS-Lite model can not be reduced to a CGN/AFTR + tunnel. DS-Lite should be first seen as an IP connectivity service. This service can be defined as follows: * delivery of IPv4 connectivity over an IPv6-capable network. * delivery of native IPv6 connectivity * DS-Lite serviced customers are assigned with IPv6 prefix and no IPv4 address. The unicast portion of the service is defined in RFC6333 and is implemented using a tunnel + CGN. The multicast portion of the service is defined in draft-ietf-softwire-dslite-multicast. This portion of the service can be defined as follows: * delivery of IPv4 multicast content using native IPv6 multicast capabilities * delivery of native IPv6 multicast content The solution proposed in draft-ietf-softwire-dslite-multicast is designed to allow DS-Lite serviced customers be delivered IPv4 multicast services. A side note, I agree with Stig and Woj the proposed solution can be generalized to cover any 4-6-4 scenario. This can be done easily by updating the draft (abstract and introduction) to reflect the change of scope of use cases. We didn't had the ambition to define a generic solution when we wrote this draft, we focused mainly on the DS-Lite context. If there is no objection from the WG, we can implement that change. Cheers, Med -Message d'origine- De : softwire issue tracker [mailto:trac+softw...@tools.ietf.org] Envoyé : vendredi 13 juillet 2012 23:55 À : draft-ietf-softwire-dslite-multic...@tools.ietf.org; sarik...@ieee.org Cc : softwires@ietf.org Objet : Re: [softwire] #10: Nothing in common with DS-Lite #10: Nothing in common with DS-Lite Changes (by sarikaya@.): * owner: sarikaya@. = draft-ietf-softwire-dslite-multicast@. -- -+- Reporter: sarikaya@. | Owner: draft-ietf-softwire-dslite- Type: defect | multicast@. Priority: major| Status: new Component: dslite- | Milestone: milestone1 multicast | Version: 2.0 Severity: In WG Last | Resolution: Call | Keywords: tunneling| -+- Ticket URL: http://trac.tools.ietf.org/wg/softwire/trac/ticket/10#comment:1 softwire http://tools.ietf.org/softwire/ ___ 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] map-00: review on the mode 1:1
Ole's and Satoru's eaerlier replies on this thread described the how, and even Maoke's earlier post on this thread acknowledged EA=0 with full IPv4 to be a naturally established case of the MAP. EA=0 simply means that there isn't IPv4 (or PSID) info in the IPv6 prefix. In terms of your question: When the EA=0, the full v4 address is derived via DHCP (or other) configuration. If the operator wants to configure address sharing, then a PSID is also required to be configured. This is saying , you have to have an IPv4 address, and besides that if you want address sharing, you have to configure a port range via a PSID, which is unlikely to be confusing to any operator who is interested in doing any of this. That said, even if it the draft can better articulate this use, (which draft-00 actually sought to do), that not being so is hardly grounds for having yet another solution and draft to deal with this use-case. In terms of causing operator confusion, that by far is more confusing. Thanks, Woj. On 27 July 2012 14:39, Lee, Yiu yiu_...@cable.comcast.com wrote: Woj, I am confused. You said given that EA=0 is already covered (eg embedding of full IPv4 address, no address sharing, if not the other case). If I read the spec right, this is my understanding: If I want to embed full v4 address in the CE v6 address, the v4 address will be embedded in the EA. If so, how would EA=0? The EA bits encode the CE specific IPv4 address and port information. The EA bits can contain a full or part of an IPv4 prefix or address, and in the shared IPv4 address case contains a Port-Set Identifier (PSID). I prefer one solution vs. N solutions given that the one solution can logically solve all problems and doesn't cause confusion. Consider we agreed on including 1:1 MAP. When an operator deployed it, he had to ask if I want to share v4 addresses, should I put the v4 info in the EA or set EA=0 and provision PSID? It will create unnecessary confusion. Simply put I am not calling out for a remove that part of the spec complicate it case. My position is quite an opposite. I am calling out for not adding confusion to complicate a spec. In the end, it is up to WG to decide. Thanks, Yiu From: Wojciech Dec wdec.i...@gmail.com Date: Friday, July 27, 2012 8:06 AM To: Yiu L. LEE yiu_...@cable.comcast.com Cc: Ole Trøan otr...@employees.org, Softwires-wg softwires@ietf.org Subject: Re: [Softwires] map-00: review on the mode 1:1 On 26 July 2012 16:59, Lee, Yiu yiu_...@cable.comcast.com wrote: Ole, IMHO the WG will need to decide whether EA=0 should be covered at all. If not, then the draft could explicitly mention EA must be 0 and must contain v4 information in the CE address. If the WG decided this needed to be cover, I would recommend to have a new draft to cover it and leave EA=0 undefined in the base draft. What are the technical arguments for making such a decision? Furthermore, given that EA=0 is already covered (eg embedding of full IPv4 address, no address sharing, if not the other case) you appear to be calling out for a remove that part of the spec complicate it case, even though not disputing the use-fullness of the use-case. Seems a sure way to get us from 1 solution to N solutions just for the sake of it. Thanks, Woj. Thanks, Yiu On 7/26/12 6:22 AM, Ole Trøan otr...@employees.org wrote: Yiu, Set EA bits=0 only saves bits in v6 address and decouples v4/v6 address dependency. It doesn't bring any new function compared to embedding full v4 address in the EA-bit. However, the operation models of EA-bit0 or =0 are very different. By the way, this works only for MAP-E. I fail to see why we want to include this in the base spec. what do you say in the spec if EA=0 and provisioned IPv4 prefix length = 32. the spec has to say something about this to be complete. cheers, Ole Thanks, Yiu On 7/25/12 9:45 PM, Satoru Matsushima satoru.matsush...@gmail.com wrote: Hi Yiu, On 2012/07/26, at 4:08, Lee, Yiu wrote: Ole, Where can I get the formal definition of 1:1 mode? My understanding of 1:1 refers to one public IPv4 address per subscriber but you refer very specific to decoupling IPv4 and IPv6 addresses. It doesn't 1:1 in MAP and 4rd context, because embedding full ipv4 address in ea-bits is as a result of prefix allocation operation. Before MAP was accepted as WG item, MAP was proposed to embed IPv4 address information (EA bits 0) in the CE IPv6 address to achieve stateless. No, there was no such definition for EA-bits length restriction. Now there is a new proposal to add a new feature to have the IPv4 information in the BR only. This change requires to provision individual subscriber information to the BR (instead of aggregated information). Benefit are saving bits and breaking v4 and v6 address dependency. There's no change from previous spec, to just
Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite
Re-, Yes, the CGN is not required. This design choice is motivated in the draft (read the Introduction text). What is the issue then? If you are saying this is a generic solution and it does not apply only to ds-lite, this point is taken (see the note below). Cheers, Med De : Wojciech Dec [mailto:wdec.i...@gmail.com] Envoyé : vendredi 27 juillet 2012 14:44 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwire issue tracker; draft-ietf-softwire-dslite-multic...@tools.ietf.org; sarik...@ieee.org; softwires@ietf.org Objet : Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite Med, the point is that the DS-Lite (CGN AFTR) solution is not necessary to be deployed for the multicast solution described here to work. As to how this ended up being charterd in Softwire I don't know and IMO it doesn't make much sense. Regards, Woj. On 27 July 2012 13:48, mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com wrote: Dear all, I really don't understand this issue. It is even misplaced to have this comment at this stage, since this is a document which has been adopted by the WG and the solution it specifies is the same as the one reviewed by the WG prior to its adoption (i.e., since April 2011). Anyway, below a tentative to explain the overall rationale: DS-Lite model can not be reduced to a CGN/AFTR + tunnel. DS-Lite should be first seen as an IP connectivity service. This service can be defined as follows: * delivery of IPv4 connectivity over an IPv6-capable network. * delivery of native IPv6 connectivity * DS-Lite serviced customers are assigned with IPv6 prefix and no IPv4 address. The unicast portion of the service is defined in RFC6333 and is implemented using a tunnel + CGN. The multicast portion of the service is defined in draft-ietf-softwire-dslite-multicast. This portion of the service can be defined as follows: * delivery of IPv4 multicast content using native IPv6 multicast capabilities * delivery of native IPv6 multicast content The solution proposed in draft-ietf-softwire-dslite-multicast is designed to allow DS-Lite serviced customers be delivered IPv4 multicast services. A side note, I agree with Stig and Woj the proposed solution can be generalized to cover any 4-6-4 scenario. This can be done easily by updating the draft (abstract and introduction) to reflect the change of scope of use cases. We didn't had the ambition to define a generic solution when we wrote this draft, we focused mainly on the DS-Lite context. If there is no objection from the WG, we can implement that change. Cheers, Med -Message d'origine- De : softwire issue tracker [mailto:trac+softw...@tools.ietf.orgmailto:trac%2bsoftw...@tools.ietf.org] Envoyé : vendredi 13 juillet 2012 23:55 À : draft-ietf-softwire-dslite-multic...@tools.ietf.orgmailto:draft-ietf-softwire-dslite-multic...@tools.ietf.org; sarik...@ieee.orgmailto:sarik...@ieee.org Cc : softwires@ietf.orgmailto:softwires@ietf.org Objet : Re: [softwire] #10: Nothing in common with DS-Lite #10: Nothing in common with DS-Lite Changes (by sarikaya@.): * owner: sarikaya@. = draft-ietf-softwire-dslite-multicast@. -- -+- Reporter: sarikaya@. | Owner: draft-ietf-softwire-dslite- Type: defect | multicast@. Priority: major| Status: new Component: dslite- | Milestone: milestone1 multicast | Version: 2.0 Severity: In WG Last | Resolution: Call | Keywords: tunneling| -+- Ticket URL: http://trac.tools.ietf.org/wg/softwire/trac/ticket/10#comment:1 softwire http://tools.ietf.org/softwire/ ___ 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] map-00: review on the mode 1:1
Woj, According to your description, it is clear that the way to deal with EA=0 is quite different with EA0. Mixing them together will not only make MAP losing the initial no state in the ISP network paradigm spirit, but also make MAP a lot more complex and confusing. Actually, the use case for EA=0 and EA0 stems from different requirements, it is nature to treat them with seperately. Best wishes Qiong On Fri, Jul 27, 2012 at 9:03 PM, Wojciech Dec wdec.i...@gmail.com wrote: Ole's and Satoru's eaerlier replies on this thread described the how, and even Maoke's earlier post on this thread acknowledged EA=0 with full IPv4 to be a naturally established case of the MAP. EA=0 simply means that there isn't IPv4 (or PSID) info in the IPv6 prefix. In terms of your question: When the EA=0, the full v4 address is derived via DHCP (or other) configuration. If the operator wants to configure address sharing, then a PSID is also required to be configured. This is saying , you have to have an IPv4 address, and besides that if you want address sharing, you have to configure a port range via a PSID, which is unlikely to be confusing to any operator who is interested in doing any of this. That said, even if it the draft can better articulate this use, (which draft-00 actually sought to do), that not being so is hardly grounds for having yet another solution and draft to deal with this use-case. In terms of causing operator confusion, that by far is more confusing. Thanks, Woj. On 27 July 2012 14:39, Lee, Yiu yiu_...@cable.comcast.com wrote: Woj, I am confused. You said given that EA=0 is already covered (eg embedding of full IPv4 address, no address sharing, if not the other case). If I read the spec right, this is my understanding: If I want to embed full v4 address in the CE v6 address, the v4 address will be embedded in the EA. If so, how would EA=0? The EA bits encode the CE specific IPv4 address and port information. The EA bits can contain a full or part of an IPv4 prefix or address, and in the shared IPv4 address case contains a Port-Set Identifier (PSID). I prefer one solution vs. N solutions given that the one solution can logically solve all problems and doesn't cause confusion. Consider we agreed on including 1:1 MAP. When an operator deployed it, he had to ask if I want to share v4 addresses, should I put the v4 info in the EA or set EA=0 and provision PSID? It will create unnecessary confusion. Simply put I am not calling out for a remove that part of the spec complicate it case. My position is quite an opposite. I am calling out for not adding confusion to complicate a spec. In the end, it is up to WG to decide. Thanks, Yiu From: Wojciech Dec wdec.i...@gmail.com Date: Friday, July 27, 2012 8:06 AM To: Yiu L. LEE yiu_...@cable.comcast.com Cc: Ole Trøan otr...@employees.org, Softwires-wg softwires@ietf.org Subject: Re: [Softwires] map-00: review on the mode 1:1 On 26 July 2012 16:59, Lee, Yiu yiu_...@cable.comcast.com wrote: Ole, IMHO the WG will need to decide whether EA=0 should be covered at all. If not, then the draft could explicitly mention EA must be 0 and must contain v4 information in the CE address. If the WG decided this needed to be cover, I would recommend to have a new draft to cover it and leave EA=0 undefined in the base draft. What are the technical arguments for making such a decision? Furthermore, given that EA=0 is already covered (eg embedding of full IPv4 address, no address sharing, if not the other case) you appear to be calling out for a remove that part of the spec complicate it case, even though not disputing the use-fullness of the use-case. Seems a sure way to get us from 1 solution to N solutions just for the sake of it. Thanks, Woj. Thanks, Yiu On 7/26/12 6:22 AM, Ole Trøan otr...@employees.org wrote: Yiu, Set EA bits=0 only saves bits in v6 address and decouples v4/v6 address dependency. It doesn't bring any new function compared to embedding full v4 address in the EA-bit. However, the operation models of EA-bit0 or =0 are very different. By the way, this works only for MAP-E. I fail to see why we want to include this in the base spec. what do you say in the spec if EA=0 and provisioned IPv4 prefix length = 32. the spec has to say something about this to be complete. cheers, Ole Thanks, Yiu On 7/25/12 9:45 PM, Satoru Matsushima satoru.matsush...@gmail.com wrote: Hi Yiu, On 2012/07/26, at 4:08, Lee, Yiu wrote: Ole, Where can I get the formal definition of 1:1 mode? My understanding of 1:1 refers to one public IPv4 address per subscriber but you refer very specific to decoupling IPv4 and IPv6 addresses. It doesn't 1:1 in MAP and 4rd context, because embedding full ipv4 address in ea-bits is as a result of prefix allocation operation. Before MAP was accepted as WG item, MAP was proposed to
Re: [Softwires] map-00: review on the mode 1:1
On Fri, Jul 27, 2012 at 9:28 PM, Qiong bingxu...@gmail.com wrote: Woj, According to your description, it is clear that the way to deal with EA=0 is quite different with EA0. Mixing them together will not only make MAP losing the initial no state in the ISP network paradigm spirit, but also make MAP a lot more complex and confusing. Actually, the use case for EA=0 and EA0 stems from different requirements, it is nature to treat them with seperately. And for the case of EA bits=0, 90% of the MAP specification is not needed. (v4 addr, PSID) provisioning, BR v6 addr provisioning and (v4 addr, PSID, v6 addr) binding on BR, that's all. No one needs to learn any thing about mapping rules what so ever. Best wishes Qiong On Fri, Jul 27, 2012 at 9:03 PM, Wojciech Dec wdec.i...@gmail.com wrote: Ole's and Satoru's eaerlier replies on this thread described the how, and even Maoke's earlier post on this thread acknowledged EA=0 with full IPv4 to be a naturally established case of the MAP. EA=0 simply means that there isn't IPv4 (or PSID) info in the IPv6 prefix. In terms of your question: When the EA=0, the full v4 address is derived via DHCP (or other) configuration. If the operator wants to configure address sharing, then a PSID is also required to be configured. This is saying , you have to have an IPv4 address, and besides that if you want address sharing, you have to configure a port range via a PSID, which is unlikely to be confusing to any operator who is interested in doing any of this. That said, even if it the draft can better articulate this use, (which draft-00 actually sought to do), that not being so is hardly grounds for having yet another solution and draft to deal with this use-case. In terms of causing operator confusion, that by far is more confusing. Thanks, Woj. On 27 July 2012 14:39, Lee, Yiu yiu_...@cable.comcast.com wrote: Woj, I am confused. You said given that EA=0 is already covered (eg embedding of full IPv4 address, no address sharing, if not the other case). If I read the spec right, this is my understanding: If I want to embed full v4 address in the CE v6 address, the v4 address will be embedded in the EA. If so, how would EA=0? The EA bits encode the CE specific IPv4 address and port information. The EA bits can contain a full or part of an IPv4 prefix or address, and in the shared IPv4 address case contains a Port-Set Identifier (PSID). I prefer one solution vs. N solutions given that the one solution can logically solve all problems and doesn't cause confusion. Consider we agreed on including 1:1 MAP. When an operator deployed it, he had to ask if I want to share v4 addresses, should I put the v4 info in the EA or set EA=0 and provision PSID? It will create unnecessary confusion. Simply put I am not calling out for a remove that part of the spec complicate it case. My position is quite an opposite. I am calling out for not adding confusion to complicate a spec. In the end, it is up to WG to decide. Thanks, Yiu From: Wojciech Dec wdec.i...@gmail.com Date: Friday, July 27, 2012 8:06 AM To: Yiu L. LEE yiu_...@cable.comcast.com Cc: Ole Trøan otr...@employees.org, Softwires-wg softwires@ietf.org Subject: Re: [Softwires] map-00: review on the mode 1:1 On 26 July 2012 16:59, Lee, Yiu yiu_...@cable.comcast.com wrote: Ole, IMHO the WG will need to decide whether EA=0 should be covered at all. If not, then the draft could explicitly mention EA must be 0 and must contain v4 information in the CE address. If the WG decided this needed to be cover, I would recommend to have a new draft to cover it and leave EA=0 undefined in the base draft. What are the technical arguments for making such a decision? Furthermore, given that EA=0 is already covered (eg embedding of full IPv4 address, no address sharing, if not the other case) you appear to be calling out for a remove that part of the spec complicate it case, even though not disputing the use-fullness of the use-case. Seems a sure way to get us from 1 solution to N solutions just for the sake of it. Thanks, Woj. Thanks, Yiu On 7/26/12 6:22 AM, Ole Trøan otr...@employees.org wrote: Yiu, Set EA bits=0 only saves bits in v6 address and decouples v4/v6 address dependency. It doesn't bring any new function compared to embedding full v4 address in the EA-bit. However, the operation models of EA-bit0 or =0 are very different. By the way, this works only for MAP-E. I fail to see why we want to include this in the base spec. what do you say in the spec if EA=0 and provisioned IPv4 prefix length = 32. the spec has to say something about this to be complete. cheers, Ole Thanks, Yiu On 7/25/12 9:45 PM, Satoru Matsushima satoru.matsush...@gmail.com wrote: Hi Yiu, On 2012/07/26, at 4:08, Lee, Yiu wrote: Ole, Where can I get the formal definition of 1:1 mode? My
Re: [Softwires] map-00: review on the mode 1:1
On 7/27/12 2:39 PM, Lee, Yiu wrote: The EA bits encode the CE specific IPv4 address and port information. The EA bits can contain a full or part of an IPv4 prefix or address, and in the shared IPv4 address case contains a Port-Set Identifier (PSID). I prefer one solution vs. N solutions given that the one solution can logically solve all problems and doesn't cause confusion. Consider we agreed on including 1:1 MAP. When an operator deployed it, he had to ask if I want to share v4 addresses, should I put the v4 info in the EA or set EA=0 and provision PSID? It will create unnecessary confusion. Simply put I am not calling out for a remove that part of the spec complicate it case. My position is quite an opposite. I am calling out for not adding confusion to complicate a spec. Hi, I'm just admiring how the WG (usual suspects) manages to talk about the intention to simplify things and at the end everything ends up three times more complex than at the beginning. In the RFC6346 we specified the architecture and the idea of A+P way of sharing resources. The idea was simple, clean and understandable. Now even I don't understand completely A+P anymore and that's probably a bad sign - and adding also a 4RD flavor with all the header hacks did not help either. So, on 1:1 - Idea of having 1:1 is simply to be able to do gradual deployment of A+P. In ideal world, ISP today would be able to buy from his favorite vendor A+P solution, started sending out new CPEs that are A+P capable/aware and connect them to PRR with full IP address assigned - so no change for a user as for now. Operator would be also able to change the CPE-base with sending new CPEs to old customers when they break. When operator starts getting short on IPv4 supplies, he simply introduces address sharing and changes the customers communication behaviour with a flick of the switch on services configuration page - or even better, customer applies for sharing because less price of the deal or something similar. In this case CPE gets port-restricted address next time it reconnects. So, from operational point of view, it is very important that the switch from 1:1 to sharing model is smooth, easy and a matter of one checkbox in services webpage - and it should be done on per-customer granularity. That's it. Very simple. That was how the idea should work in ideal world. But we are not there. A+P was delayed for years because of some people here - but finally even those people understood that this is the only alternative to CGN rubbish, that is currently taking over the Internet infrastructure. Please stop complicating things and fighting whose flavor is better or who's * is longer and loosing time. We need solid standard asap and I really don't care whose name is on the top of the RFC(s). Med correctly pointed to the skech in RFC6346 and I hope just options 1 and 2 will be used in real world. Cheers, Jan P.S: Unfortunately I cannot make it to Vancouver, but I encourage you all to go into that room, lock the door and don't leave it without a result and a clear idea, how to move forward quickly. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [softwire] #5: Problems of MAP-T and MAP-E with sites that already use subnet ID = 0
On 25 July 2012 16:13, Rémi Després despres.r...@laposte.net wrote: Le 2012-07-25 à 15:59, Wojciech Dec (wdec) a écrit : On 25/07/2012 15:47, Rémi Després despres.r...@laposte.net wrote: take it to 6man. 6man has to be involved, sure, but Softwire should first be clear about the purpose, and possible drawbacks if any. If you see such drawbacks, please clarify. Here's one: I'd like my insert name of your favorite device class to be guaranteed *never ever* to conflict. Can I also get a V octet for $my_device_class? Sorry I couldn't decipher this. How many V-octets do you think the IETF should assign, and why should the V-octed belong to your proposed device/use-category? One may want the V-octet to be used for Next gen TVs, etc. This is a problem discussion for 6man, which has been said before... -Woj. RD -Woj. Thanks, RD 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] DHCPv6 section of the 4rd draft
On 24.07.2012 15:10, Rémi Després wrote: Hi, Tomek, Hi Remi. hi all, Since you are the known DHCP expert in Softwire concerning stateless Thank you for your kind words. I just know DHCPv6 a bit, but I definitely don't consider myself an expert in stateless solutions. solutions, could you kindly review section 4.8 of the 4rd-03 draft, and comment on the ML its use of DHCPv6? I must admit that I haven't read 4rd draft in a long time. Unfortunately, I won't be able to review it before DHC meeting. Actually, it makes sense to do the 4rd review after DHC WG meeting. MAP options are going to be presented there, so I will hopefully be able to take advantage of other comments from DHC WG as MAP and 4rd options are quite similar. I haven't read 4rd-03 yet, just briefly looked at Section 4.8. Having said that, I've got a question to 4rd authors. I see there are significant similarities between MAP and 4rd options. Would you consider merging them a viable option? If all other MAP-4rd unification attempts fail, perhaps at least provisioning method could be common? (Doing so, of course, will not prejudge what the WG will decide concerning MAP-T+E vs 4rd.) You definitely overestimate my capabilities. I have very serious doubts that the whole WG would make a decision based on my comments. :-) In particular, the map-dhcp draft which will soon be a WG document has a container which isn't present in 4rd. Would it be recommend to add one (and if yes for which reason(s))? Here are some arguments why I think such a container make sense: 1. Some parameters may apply to all rules. Currently there is only one such parameter defined (transport mode), but others may appear once MAP evolves. 2. Easier client-server interaction. With a single container, client just signals support for MAP by requesting MAP_FLAGS option in ORO and server responds with MAP_FLAGS option with whatever sub-options are appropriate for a given client. Without container, client would be expected to request several options (MAP_FLAGS, MAP_RULE, ...) in ORO. But how is server is supposed to behave if a (misimplemented) client requests only MAP_FLAGS for example? Or only asks for basic rules? Such approach makes sanity checking and error recovery more difficult. 3. Multiple MAP domains. Sometimes there are discussions about multiple MAP domains. I haven't followed it closely, so I don't know if the latest conclusion is that they make sense or not. However, even if MAP authors (and the whole Softwires WG in general) decides that they are not valid, there may be cases when one server will provide more than one domain anyway. Look at discussion in homenet and the problem with multiple provisioning domains (like th concept of having a single home router connected to multiple ISPs). Put it simply, a container option makes multiple domains doable, if we ever decide that such a thing is useful. 4. It's easier for clients that don't support MAP. That is really a minor point, but clients that don't support MAP will complain about just a single unknown option, not many. Sure, in a perfect world, client is not expected to receive an option that it never requested. But there are people who configure their servers to force some options, regardless requested or not. 5. There's no actual bandwidth waste with container. There would be a minimal overhead of 4 octets if it was just a container. However, since MAP and 4rd both require an option with some information, there's no waste. 6. Forward compatibility. Let's assume that 4rd is standardized. What would you do if the next day after its publication someone comes with cool new idea for improvement or optimization that requires passing extra parameter to client? You would have to define a new option and it wouldn't work with old implementations. With a container, you have at least some chances to make it work. One may say that this is a weak argument, as old implementations will not know what to do with an unknown option. However, many implementations handle contents of the option be calling external script. So extending support for such extra sub-option would require updating just a script, not the whole client software. If you take those arguments one by one, each of them can be considered not important enough to warrant such a container, but if you add them all up, it is just much easier do go with a container. At least that is my opinion on that subject. Cheers, Tomek ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [softwire] #5: Problems of MAP-T and MAP-E with sites that already use subnet ID = 0
Le 2012-07-27 à 16:20, Wojciech Dec a écrit : On 25 July 2012 16:13, Rémi Després despres.r...@laposte.net wrote: Le 2012-07-25 à 15:59, Wojciech Dec (wdec) a écrit : On 25/07/2012 15:47, Rémi Després despres.r...@laposte.net wrote: take it to 6man. 6man has to be involved, sure, but Softwire should first be clear about the purpose, and possible drawbacks if any. If you see such drawbacks, please clarify. Here's one: I'd like my insert name of your favorite device class to be guaranteed *never ever* to conflict. Can I also get a V octet for $my_device_class? Sorry I couldn't decipher this. How many V-octets do you think the IETF should assign, and why should the V-octed belong to your proposed device/use-category? One may want the V-octet to be used for Next gen TVs, etc. This is a problem discussion for 6man, which has been said before... 1. Well, the term V octet only identifies a particular value of the interface ID first octet. u octet identifies another value of this same octet (but a value that, contrary to the V-octet value, can be found in local-scope addresses, and therefore isn't reserved). What name NNN will be given to this field in general (independently of its reserved values) remains open. I agree that this is is a 6man matter. 2. You ask how many values of the NNN field the IETF should assign in the future. This is is obviously uncertain. OTOH, What is sure is that, with 6 free bits and only assigned value for V, there is plenty room for future uses, especially since: - no other use has been identified in 14 years - one future value can be reserved to identify an extended format, thus largely increasing the number of reservable patterns. 3. If no WG would be allowed to propose using the extension mechanism of RFC2373/4291, what, in your understanding, would be its purpose? RD -Woj. RD -Woj. Thanks, RD 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] DHCPv6 section of the 4rd draft
Le 2012-07-27 à 16:55, Tomek Mrugalski a écrit : On 24.07.2012 15:10, Rémi Després wrote: Hi, Tomek, Hi Remi. hi all, Since you are the known DHCP expert in Softwire concerning stateless Thank you for your kind words. I just know DHCPv6 a bit, but I definitely don't consider myself an expert in stateless solutions. solutions, could you kindly review section 4.8 of the 4rd-03 draft, and comment on the ML its use of DHCPv6? I must admit that I haven't read 4rd draft in a long time. Unfortunately, I won't be able to review it before DHC meeting. Actually, it makes sense to do the 4rd review after DHC WG meeting. MAP options are going to be presented there, so I will hopefully be able to take advantage of other comments from DHC WG as MAP and 4rd options are quite similar. I haven't read 4rd-03 yet, just briefly looked at Section 4.8. Having said that, I've got a question to 4rd authors. I see there are significant similarities between MAP and 4rd options. Would you consider merging them a viable option? If all other MAP-4rd unification attempts fail, perhaps at least provisioning method could be common? Well, the WG objective before the Paris meeting was clearly to have only one standard, MAP-T, MAP-E or 4rd. 4rd has been carefully designed satisfy requirements of both MAP-T and MAP-E in a single design, and abundantly checked concerning this objective. With it, operators don't need to make a choice, and get operational advantages of T and E. (This is clearly challenged by some participants, but so far without arguments that have been convincing.) If IETF would prefer 3 forwarding variants instead of one, right, the provisioning method should at least be aligned. (Doing so, of course, will not prejudge what the WG will decide concerning MAP-T+E vs 4rd.) You definitely overestimate my capabilities. I have very serious doubts that the whole WG would make a decision based on my comments. :-) Just meaning that by working a little on 4rd, you shouldn't be considered by anyone as unfaithful to a group for which you did important work. In particular, the map-dhcp draft which will soon be a WG document has a container which isn't present in 4rd. Would it be recommend to add one (and if yes for which reason(s))? Here are some arguments why I think such a container make sense: 1. Some parameters may apply to all rules. Currently there is only one such parameter defined (transport mode), but others may appear once MAP evolves. 2. Easier client-server interaction. With a single container, client just signals support for MAP by requesting MAP_FLAGS option in ORO and server responds with MAP_FLAGS option with whatever sub-options are appropriate for a given client. Without container, client would be expected to request several options (MAP_FLAGS, MAP_RULE, ...) in ORO. But how is server is supposed to behave if a (misimplemented) client requests only MAP_FLAGS for example? Or only asks for basic rules? Such approach makes sanity checking and error recovery more difficult. Point 2 understood, and in my understanding sufficient a justification. 3. Multiple MAP domains. Sometimes there are discussions about multiple MAP domains. I haven't followed it closely, so I don't know if the latest conclusion is that they make sense or not. However, even if MAP authors (and the whole Softwires WG in general) decides that they are not valid, there may be cases when one server will provide more than one domain anyway. Look at discussion in homenet and the problem with multiple provisioning domains (like th concept of having a single home router connected to multiple ISPs). Put it simply, a container option makes multiple domains doable, if we ever decide that such a thing is useful. 4. It's easier for clients that don't support MAP. That is really a minor point, but clients that don't support MAP will complain about just a single unknown option, not many. Sure, in a perfect world, client is not expected to receive an option that it never requested. But there are people who configure their servers to force some options, regardless requested or not. 5. There's no actual bandwidth waste with container. There would be a minimal overhead of 4 octets if it was just a container. However, since MAP and 4rd both require an option with some information, there's no waste. 6. Forward compatibility. Let's assume that 4rd is standardized. What would you do if the next day after its publication someone comes with cool new idea for improvement or optimization that requires passing extra parameter to client? You would have to define a new option and it wouldn't work with old implementations. With a container, you have at least some chances to make it work. One may say that this is a weak argument, as old implementations will not know what to do with an unknown option. However, many implementations handle contents of the option be calling external script. So
Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite
Hi On 7/27/2012 4:48 AM, mohamed.boucad...@orange.com wrote: Dear all, I really don't understand this issue. It is even misplaced to have this comment at this stage, since this is a document which has been adopted by the WG and the solution it specifies is the same as the one reviewed by the WG prior to its adoption (i.e., since April 2011). Anyway, below a tentative to explain the overall rationale: DS-Lite model can not be reduced to a CGN/AFTR + tunnel. DS-Lite should be first seen as an IP connectivity service. This service can be defined as follows: * delivery of IPv4 connectivity over an IPv6-capable network. * delivery of native IPv6 connectivity * DS-Lite serviced customers are assigned with IPv6 prefix and no IPv4 address. The unicast portion of the service is defined in RFC6333 and is implemented using a tunnel + CGN. The multicast portion of the service is defined in draft-ietf-softwire-dslite-multicast. This portion of the service can be defined as follows: * delivery of IPv4 multicast content using native IPv6 multicast capabilities * delivery of native IPv6 multicast content The solution proposed in draft-ietf-softwire-dslite-multicast is designed to allow DS-Lite serviced customers be delivered IPv4 multicast services. I think I agree with the above. A side note, I agree with Stig and Woj the proposed solution can be generalized to cover any 4-6-4 scenario. This can be done easily by updating the draft (abstract and introduction) to reflect the change of scope of use cases. We didn't had the ambition to define a generic solution when we wrote this draft, we focused mainly on the DS-Lite context. If there is no objection from the WG, we can implement that change. This is all I've been asking for. An update to abstract/introduction to indicate that it is a generic solution. And then say that DS-Lite is one of the use-cases. You can even say that the solution was developed to solve the problem for DS-Lite. All I want is to make it clear that it is a generic solution. Stig Cheers, Med -Message d'origine- De : softwire issue tracker [mailto:trac+softw...@tools.ietf.org] Envoyé : vendredi 13 juillet 2012 23:55 À : draft-ietf-softwire-dslite-multic...@tools.ietf.org; sarik...@ieee.org Cc : softwires@ietf.org Objet : Re: [softwire] #10: Nothing in common with DS-Lite #10: Nothing in common with DS-Lite Changes (by sarikaya@.): * owner: sarikaya@. = draft-ietf-softwire-dslite-multicast@. -- -+- Reporter: sarikaya@. | Owner: draft-ietf-softwire-dslite- Type: defect | multicast@. Priority: major| Status: new Component: dslite- | Milestone: milestone1 multicast | Version: 2.0 Severity: In WG Last | Resolution: Call | Keywords: tunneling| -+- Ticket URL: http://trac.tools.ietf.org/wg/softwire/trac/ticket/10#comment:1 softwire http://tools.ietf.org/softwire/ ___ 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] [softwire] #10: Nothing in common with DS-Lite
Hi Med, My comments below. Please do not take them personal. No offense. Please, please. On Fri, Jul 27, 2012 at 6:48 AM, mohamed.boucad...@orange.com wrote: Dear all, I really don't understand this issue. It is even misplaced to have this comment at this stage, since this is a document which has been adopted by the WG and the solution it specifies is the same as the one reviewed by the WG prior to its adoption (i.e., since April 2011). Anyway, below a tentative to explain the overall rationale: DS-Lite model can not be reduced to a CGN/AFTR + tunnel. DS-Lite should be first seen as an IP connectivity service. This service can be defined as follows: * delivery of IPv4 connectivity over an IPv6-capable network. * delivery of native IPv6 connectivity * DS-Lite serviced customers are assigned with IPv6 prefix and no IPv4 address. The unicast portion of the service is defined in RFC6333 and is implemented using a tunnel + CGN. The multicast portion of the service is defined in draft-ietf-softwire-dslite-multicast. This portion of the service can be defined as follows: * delivery of IPv4 multicast content using native IPv6 multicast capabilities * delivery of native IPv6 multicast content The solution proposed in draft-ietf-softwire-dslite-multicast is designed to allow DS-Lite serviced customers be delivered IPv4 multicast services. These are religious arguments. Translation multicast integrates well with several IPv6 transition technologies. MAP-T is one. NAT64 is another, 4rd also. But not MAP-E. Let's use translation multicast with those technologies. No matter what you want to believe, DS-Lite is a tunneling technology. Why do you think DS-Lite was standardized in Softwires WG? Same thing with 6rd. Remember softwire means tunnel. Translation has only been added to Softwires WG recently after Behave WG stopped working on it. A side note, I agree with Stig and Woj the proposed solution can be generalized to cover any 4-6-4 scenario. This can be done easily by updating the draft (abstract and introduction) to reflect the change of scope of use cases. We didn't had the ambition to define a generic solution when we wrote this draft, we focused mainly on the DS-Lite context. If there is no objection from the WG, we can implement that change. So you agree that it is a generic solution and nothing in common with DS-Lite. Regards, Behcet ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
