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 Softwires
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
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] 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] 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
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] map-00: review on the mode 1:1
Ole, As I suggested earlier, you could simply say that the WHOLE ARCHITECTURE is based on IPv4-IPv6 address embedding and because setting EA bits=0 changes this very basic assumption, it's not allowed/supported in MAP. IMHO it's the best way to keep MAP clean and clear. And I don't think it'll cause problems: you want statelessness, you couple v4-v6 addressing and use MAP; you want v4-v6 addressing independency rather than statelessness, then that's another story. On Thu, Jul 26, 2012 at 6:22 PM, 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
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 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 got a general question. The current MAP support 1:1 mode where EA-bit is a full 32-bit address. Why we want to reinvent a wheel to create another 1:1 mode? The only difference is to move the configuration from DHCP server to rules in the BR. Did I miss something? Thanks, Yiu From: Wojciech Dec wdec.i...@gmail.com Date: Monday, July 23, 2012 4:06 AM To: Qiong bingxu...@gmail.com Cc: Softwires-wg softwires@ietf.org Subject: Re: [Softwires] map-00: review on the mode 1:1 Qiong, On 21 July 2012 11:46, Qiong bingxu...@gmail.com wrote: Hi, Woj, This is not only about determining which parameter to explicitly exist in MAP rule, but also the configuration in BR. If you include PSID explicitly, then 1) you need to configure per-subscriber rule in BR since the value of PSID for different CPEs are different. This will take a lot of workload for operators and it is obviously not the objective of any stateless solution. Stateless does not mean configuration less, and never did. Even without an explicit PSID one could have thousands of rules configured, if one chooses to deploy it that way. 2) IPv6 prefix has already carry the PSID implicitly, and the PSID in MAP rule is redundant. Therefore, I don't see the reason to include PSID explicitly in MAP architecture. So you don't disagree about the use, which is good. I'm however puzzled by why you see a need for a separate architecture document specification to address the need for explicit port range, which the explicit PSID is, rather than working on a common solution... Regards, Woj. Best wishes Qiong Wojciech Dec wdec.i...@gmail.com编写： Remi, On 20 July 2012 17:03, Rémi Després despres.r...@laposte.net wrote: Hi, Wojciech, 2012-07-20 12:56, Wojciech Dec: If the use of PSIDs in rules is useful, as it appears to be, This is the point that needs to be explained. The case is straightforward A+P. For a single IPv4 address + port range it is desired to have it correspond to an IPv6 address. MAP and 4rd-u have that as a well established case with the IPv4 address and / or PSID being mapped into the IPv6 prefix, but the IPv4 address not given that it is configured on both sides (implicit). There is nothing in the MAP architecture which restricts the PSID to not be such an implicit parameter given that it can be configured at either side. -Woj. Thanks. RD then there seems to be no reason not to allow that. Regards, Woj. - maoke Regards, Woj. ___ 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] map-00: review on the mode 1:1
Yiu, I got a general question. The current MAP support 1:1 mode where EA-bit is a full 32-bit address. Why we want to reinvent a wheel to create another 1:1 mode? The only difference is to move the configuration from DHCP server to rules in the BR. Did I miss something? just the opposite. MAP supports 1:1 mode with no EA bits. all the bits are encoded in the MAP DHCP option. this is just a logical implications of the fields already in that option. cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] map-00: review on the mode 1:1
Ole, 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? Thanks, Yiu Why we want to On 7/25/12 1:04 PM, Ole Trøan otr...@employees.org wrote: Yiu, I got a general question. The current MAP support 1:1 mode where EA-bit is a full 32-bit address. Why we want to reinvent a wheel to create another 1:1 mode? The only difference is to move the configuration from DHCP server to rules in the BR. Did I miss something? just the opposite. MAP supports 1:1 mode with no EA bits. all the bits are encoded in the MAP DHCP option. this is just a logical implications of the fields already in that option. cheers, Ole smime.p7s Description: S/MIME cryptographic signature ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] map-00: review on the mode 1:1
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
Re: [Softwires] map-00: review on the mode 1:1
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. 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. 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. Questions to WG: Is it useful feature to be included in MAP? If not, why and alternative? 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 smime.p7s Description: S/MIME cryptographic signature ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] map-00: review on the mode 1:1
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
Re: [Softwires] map-00: review on the mode 1:1
Hi Satoru, 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. 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 smime.p7s Description: S/MIME cryptographic signature ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] map-00: review on the mode 1:1
Qiong, On 21 July 2012 11:46, Qiong bingxu...@gmail.com wrote: Hi, Woj, This is not only about determining which parameter to explicitly exist in MAP rule, but also the configuration in BR. If you include PSID explicitly, then 1) you need to configure per-subscriber rule in BR since the value of PSID for different CPEs are different. This will take a lot of workload for operators and it is obviously not the objective of any stateless solution. Stateless does not mean configuration less, and never did. Even without an explicit PSID one could have thousands of rules configured, if one chooses to deploy it that way. 2) IPv6 prefix has already carry the PSID implicitly, and the PSID in MAP rule is redundant. Therefore, I don't see the reason to include PSID explicitly in MAP architecture. So you don't disagree about the use, which is good. I'm however puzzled by why you see a need for a separate architecture document specification to address the need for explicit port range, which the explicit PSID is, rather than working on a common solution... Regards, Woj. Best wishes Qiong Wojciech Dec wdec.i...@gmail.com编写： Remi, On 20 July 2012 17:03, Rémi Després despres.r...@laposte.net wrote: Hi, Wojciech, 2012-07-20 12:56, Wojciech Dec: If the use of PSIDs in rules is useful, as it appears to be, This is the point that needs to be explained. The case is straightforward A+P. For a single IPv4 address + port range it is desired to have it correspond to an IPv6 address. MAP and 4rd-u have that as a well established case with the IPv4 address and / or PSID being mapped into the IPv6 prefix, but the IPv4 address not given that it is configured on both sides (implicit). There is nothing in the MAP architecture which restricts the PSID to not be such an implicit parameter given that it can be configured at either side. -Woj. Thanks. RD then there seems to be no reason not to allow that. Regards, Woj. - maoke Regards, Woj. ___ 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
Hi, Woj, This is not only about determining which parameter to explicitly exist in MAP rule, but also the configuration in BR. If you include PSID explicitly, then 1) you need to configure per-subscriber rule in BR since the value of PSID for different CPEs are different. This will take a lot of workload for operators and it is obviously not the objective of any stateless solution. 2) IPv6 prefix has already carry the PSID implicitly, and the PSID in MAP rule is redundant. Therefore, I don't see the reason to include PSID explicitly in MAP architecture. Best wishes Qiong Wojciech Dec wdec.i...@gmail.com编写： Remi, On 20 July 2012 17:03, Rémi Després despres.r...@laposte.net wrote: Hi, Wojciech, 2012-07-20 12:56, Wojciech Dec: If the use of PSIDs in rules is useful, as it appears to be, This is the point that needs to be explained. The case is straightforward A+P. For a single IPv4 address + port range it is desired to have it correspond to an IPv6 address. MAP and 4rd-u have that as a well established case with the IPv4 address and / or PSID being mapped into the IPv6 prefix, but the IPv4 address not given that it is configured on both sides (implicit). There is nothing in the MAP architecture which restricts the PSID to not be such an implicit parameter given that it can be configured at either side. -Woj. Thanks. RD then there seems to be no reason not to allow that. Regards, Woj. - maoke Regards, Woj. ___ 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
Hi Maoke, On 20 July 2012 03:17, Maoke fib...@gmail.com wrote: hi Woj, let me truncate the old text that makes this message too long. focusing on the recent replies. 2012/7/19 Wojciech Dec wdec.i...@gmail.com Hello Maoke, okay, if your MAP algorithm refers to the GMA, it is fine to state GMA is usable to address/port-set assignment and/or stateless IPv4-mapped IPv6 address generation. however, only the GMA doesn't make MAP as a mapping of address and port. the purpose of mapping is making a stateless packet transform at the IPv4/IPv6 boundary and vise versa. The mapping still happens, in the lower 64 bits. clarified. thanks. if you argue GMA is generic for universal cases of A+P ( i actually agree that ), i suggest to submit GMA separately as a standard or as an update of A+P, so that stateful/stateless solutions are able to cite it easily. That's what it was, but it was said to be too many drafts. In addition, the IPv4+PSID are still mapped to IID as per MAP. Thus there is no algorithm is abandoned case, as you put it. this a little differs from my early reading on the MAP draft stating 1:1. you clarify here that in any cases IPv4+PSID is embedded in the mapped IPv6 address. The PSID is intended to be passed as part of the Optional Port Parameters, which the draft already has as part of the FMRs, and what has also been discussed in the DT. yes we have the optional port parameters. but i didn't remember what DT discussed included the topic of having the value of PSID in the FMR. Please refer to Satoru-san's emails on the topic. on the other hand, i think current talk is going on at the WG stage rather than the DT. even if i didn't show objection to that issue in the DT, i don't think i would have been disabled to show it in the WG. This is another type of 1:1 rules, which I agree is an item of clarification in the draft, but eminently possible under the current spec as the the MAP architecture is agnostic to how the IPv6+IPv4+Rules get to the device sorry i cannot catch the meaning of the agnostic to... :P i understand how the IPv6+IPv4+Rules get to the device is the mission of MAP-DHCP rather than the MAP architecture. Agnostic to means, that the working of the MAP architecture doesn't rely on any specific MAP rule or address provisioning method. Should be noted that IPv6 addresses are also provisioned, and can be so by multiple methods. any specific MAP rule or any specific rule-making algorithm? if the former, no objection here. if the latter, i don't see anything essential other than a rule-making algorithm in the MAP architecture. and this rule-making algorithm is what i support through the MDT and the WG. No, I said, any specific MAP rule provisioning method. In other words, the MAP architecture is not tied to *how* the MAP info gets to the CPE, be that ipv6 addressing, dhcpv6 or a combination of the two. if the multiple-CE domain and the single-CE domain should have different attributes, i don't think this is not a novelty. and i am against this configuration parameter no matter if it is *stated* as a non-novelty or not. And what is the reason for this objection? does MAP intend to support mesh topology with the PSID value included in the rule? if so, i doubt any CE device (especially those having limited resources) can do with that. if it is not, the architecture happens with 2 configurations not orthogonal: if PSID, no mesh -- it confuses that the highest priority design goal of MAP is not statelessness and simplicity but the PSID. The mesh topology is, and never was, a goal above all others. MAP supports hubspoke and mesh. Even without an explictly provisioned PSID, there will be practical implementation limits to how many MAP rules a CE can have. The DMR *always* takes traffic not matching a more specific rule to the BR. therefore i am objective of introducing PSID into the rule and making the architecture stateless only in wording. If you mean that by having PSID as part of the rule, moves MAP from being stateless to stateful, then that's a misstatement. As per one of the earlier posts, stateless does NOT mean configuration less, and MAP always required configuration, with PSID as part of rules or not. How much configuration one wants to deal with is subject to specific deployment considerations, and MAP allows that amount of configuration to be optimized if a good deal of cases. The working of MAP is unchanged with the use of the PSID as part of the ruleset, given a tradeoff with resepcet to more rules. The main point here though is another: If the use of PSIDs in rules is useful, as it appears to be, then there seems to be no reason not to allow that. Regards, Woj. - maoke Regards, Woj. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] map-00: review on the mode 1:1
Hi, Wojciech, 2012-07-20 12:56, Wojciech Dec: Hi Maoke, ... therefore i am objective of introducing PSID into the rule and making the architecture stateless only in wording. If you mean that by having PSID as part of the rule, moves MAP from being stateless to stateful, then that's a misstatement. I share Maoke's understanding here. Independently of other reasons to prefer 4rd to MAP-T+E, documented elsewhere, I think that, in order to clarify what you mean, it would be useful to describe a MAP use case where PSID-in-a-rule is needed. As per one of the earlier posts, stateless does NOT mean configuration less, and MAP always required configuration, with PSID as part of rules or not. How much configuration one wants to deal with is subject to specific deployment considerations, and MAP allows that amount of configuration to be optimized if a good deal of cases. The working of MAP is unchanged with the use of the PSID as part of the ruleset, given a tradeoff with resepcet to more rules. The main point here though is another: If the use of PSIDs in rules is useful, as it appears to be, This is the point that needs to be explained. Thanks. RD then there seems to be no reason not to allow that. Regards, Woj. - maoke Regards, Woj. ___ 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
Remi, On 20 July 2012 17:03, Rémi Després despres.r...@laposte.net wrote: Hi, Wojciech, 2012-07-20 12:56, Wojciech Dec: If the use of PSIDs in rules is useful, as it appears to be, This is the point that needs to be explained. The case is straightforward A+P. For a single IPv4 address + port range it is desired to have it correspond to an IPv6 address. MAP and 4rd-u have that as a well established case with the IPv4 address and / or PSID being mapped into the IPv6 prefix, but the IPv4 address not given that it is configured on both sides (implicit). There is nothing in the MAP architecture which restricts the PSID to not be such an implicit parameter given that it can be configured at either side. -Woj. Thanks. RD then there seems to be no reason not to allow that. Regards, Woj. - maoke Regards, Woj. ___ 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
hi Woj, let me truncate the old text that makes this message too long. focusing on the recent replies. 2012/7/19 Wojciech Dec wdec.i...@gmail.com Hello Maoke, okay, if your MAP algorithm refers to the GMA, it is fine to state GMA is usable to address/port-set assignment and/or stateless IPv4-mapped IPv6 address generation. however, only the GMA doesn't make MAP as a mapping of address and port. the purpose of mapping is making a stateless packet transform at the IPv4/IPv6 boundary and vise versa. The mapping still happens, in the lower 64 bits. clarified. thanks. if you argue GMA is generic for universal cases of A+P ( i actually agree that ), i suggest to submit GMA separately as a standard or as an update of A+P, so that stateful/stateless solutions are able to cite it easily. That's what it was, but it was said to be too many drafts. In addition, the IPv4+PSID are still mapped to IID as per MAP. Thus there is no algorithm is abandoned case, as you put it. this a little differs from my early reading on the MAP draft stating 1:1. you clarify here that in any cases IPv4+PSID is embedded in the mapped IPv6 address. The PSID is intended to be passed as part of the Optional Port Parameters, which the draft already has as part of the FMRs, and what has also been discussed in the DT. yes we have the optional port parameters. but i didn't remember what DT discussed included the topic of having the value of PSID in the FMR. Please refer to Satoru-san's emails on the topic. on the other hand, i think current talk is going on at the WG stage rather than the DT. even if i didn't show objection to that issue in the DT, i don't think i would have been disabled to show it in the WG. This is another type of 1:1 rules, which I agree is an item of clarification in the draft, but eminently possible under the current spec as the the MAP architecture is agnostic to how the IPv6+IPv4+Rules get to the device sorry i cannot catch the meaning of the agnostic to... :P i understand how the IPv6+IPv4+Rules get to the device is the mission of MAP-DHCP rather than the MAP architecture. Agnostic to means, that the working of the MAP architecture doesn't rely on any specific MAP rule or address provisioning method. Should be noted that IPv6 addresses are also provisioned, and can be so by multiple methods. any specific MAP rule or any specific rule-making algorithm? if the former, no objection here. if the latter, i don't see anything essential other than a rule-making algorithm in the MAP architecture. and this rule-making algorithm is what i support through the MDT and the WG. if the multiple-CE domain and the single-CE domain should have different attributes, i don't think this is not a novelty. and i am against this configuration parameter no matter if it is *stated* as a non-novelty or not. And what is the reason for this objection? does MAP intend to support mesh topology with the PSID value included in the rule? if so, i doubt any CE device (especially those having limited resources) can do with that. if it is not, the architecture happens with 2 configurations not orthogonal: if PSID, no mesh -- it confuses that the highest priority design goal of MAP is not statelessness and simplicity but the PSID. therefore i am objective of introducing PSID into the rule and making the architecture stateless only in wording. - maoke Regards, Woj. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] map-00: review on the mode 1:1
Remark, Confusion of current 'draft-ietf-softwire-map-00' version of MAP about 1:1 is that independence between the ipv6 and ipv4 addressing could be represented as bellow: 1). ea-len equal to zero within a BMR/FMR for MAP-CE provisioning 2). only DMR provisioning for MAP-CE So in the 1), it doesn't mean NAT44 disabled on MAP CE. In the 2), it does require MAP CE to disable NAT44 for compatibility of MAP-CE(-E) be as DS-Lite B4, and MAP-CE(-T) to be compatible with stateless NAT64. cheers, --satoru On 2012/06/28, at 10:53, Maoke wrote: Question #8.4: if there is no IPv4 address nor IPv4 stack, where do we need to *disable* the NAT44? i agree with you that NAT44 is disabled here is obvious but i see it is too obvious to cost a MUST in the specification. MUST disable means WE, the HUMAN, MUST make an action according to the specification. question clarified? please confirm that the editor/author of this text refers the same thing as you interpreted. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] map-00: review on the mode 1:1
Maoke - i fully agree with you as zero-lengthed EA-bits is a naturally possible
case of MAP. however, to my understanding, even in this case the Figure 7 of
MAP addressing architecture is still appliable and therefore it implies PSID
length also equals to zero. this is the real meaning of 1:1...
Satoru - Let's think that a CE provisioned with following BMR comes from MAP
DHCPv6 options.
BMR:
o Rule-ipv6-prefix : {exact matched with CE's delegated prefix} o
Rule-ipv4-prefix : x.x.x.x/32
o EA-length : 0
o Port-param option : {PSID/length}
This BMR could be a LW46 provisioning means.
(http://www.ietf.org/mail-archive/web/softwires/current/msg04466.html )
I don't think 'it implies PSID length also equals to zero' can be derived from
'zero-lengthed EA-bits' as per the example from Satoru.
On the other hand, when the text of '1:1 mode' and '1:1 case' is mentioned in
the draft, I'd like to know what the 1st '1' the 2nd '1' stand for
respectively.
Best Regards,
Leaf
-Original Message-
From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf
Of Satoru Matsushima
Sent: Thursday, June 28, 2012 1:02 PM
To: Maoke
Cc: Softwires-wg
Subject: Re: [Softwires] map-00: review on the mode 1:1
Hi Maoke-san,
On 2012/06/27, at 20:12, Maoke wrote:
Described text for '1:1 mode' in current version would make some people
confused. We need to make clear for that.
i fully agree with you as zero-lengthed EA-bits is a naturally possible case
of MAP. however, to my understanding, even in this case the Figure 7 of MAP
addressing architecture is still appliable and therefore it implies PSID
length also equals to zero. this is the real meaning of 1:1 that is a natural
case possibly occurs rather than a mode - mode is a sort of preset
configuration. and further, it is not necessary to disable NAT44 in such
EA-null/PSID-null cases at CE.
Right, it isn't a 'mode' which changes any MAP nature.
this definitely makes the MAP spec clear. if necessary, including this
special case in the MAP draft or in the MAP deployment draft, mentioning its
usage, is what i support unless we discover any other flaws regarding this.
Thanks for clarification.
cheers,
--satoru
___
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
Maoke - Section 7.3 page 19: A MAP-E CE provisioned with only a Default Mapping Rule, as in the 1:1 case, and with no IPv4 address and port range configured by other means, MUST disable its NAT44 functionality. Question #8: what is the consequence of disabling the NAT44 functionality on CE when a subscriber having a PSID of a share IPv4 address is running behind that CE as a 1:1 mode domain? Supposed the draft is talking about the backward compatibility with DS-lite. When CE provisioned with only a Default Mapping Rule and the CE disable its NAT44 functionality, the CE turns to be B4 of DS-lite, the BR will turns to be stateful AFTR of DS-lite. But the question on the text of as in the 1:1 case seems still be there, because '1:1' continuous to puzzles us before it is defined. I don't think the as in the 1:1 case is necessary here in the context of this paragraph. Best Regards, Leaf -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Satoru Matsushima Sent: Thursday, June 28, 2012 2:32 PM To: Maoke Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 Remark, Confusion of current 'draft-ietf-softwire-map-00' version of MAP about 1:1 is that independence between the ipv6 and ipv4 addressing could be represented as bellow: 1). ea-len equal to zero within a BMR/FMR for MAP-CE provisioning 2). only DMR provisioning for MAP-CE So in the 1), it doesn't mean NAT44 disabled on MAP CE. In the 2), it does require MAP CE to disable NAT44 for compatibility of MAP-CE(-E) be as DS-Lite B4, and MAP-CE(-T) to be compatible with stateless NAT64. cheers, --satoru On 2012/06/28, at 10:53, Maoke wrote: Question #8.4: if there is no IPv4 address nor IPv4 stack, where do we need to *disable* the NAT44? i agree with you that NAT44 is disabled here is obvious but i see it is too obvious to cost a MUST in the specification. MUST disable means WE, the HUMAN, MUST make an action according to the specification. question clarified? please confirm that the editor/author of this text refers the same thing as you interpreted. ___ 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
maoke - see my analysis in the discussion thread with Dec.
That sound the homework of Woj. :-)
maoke - having a PSID for CE but no the PSID embedded in the address makes
ambiguity when mapping entry is selected for a specific IPv4 flow.
Satoru - Confusion of current 'draft-ietf-softwire-map-00' version of MAP about
1:1 is that independence between the ipv6 and ipv4 addressing could be
represented as bellow: 1). ea-len equal to zero within a BMR/FMR for MAP-CE
provisioning 2). only DMR provisioning for MAP-CE
1) Length (EA bits) = 0 sounds no mapping at CE, the provision of IPv4 address
and PSID are independent. The mapping (Fig.7) is expected to be invalid.
2) Only DMR of MRs is provisioned to CE, sounds that no BMR/FMR defined in the
draft-spec is really provisioned to CE.
maoke - my understanding is 1-IPv6 address : 1-IPv4 address.
The alternative of 1:1 might be 1x IPv6 prefix of CE - 1x {IPv4 address +
PSID} of CE, which sound the same as before as the design target, but the MAP
domain is expected only for one CE if length(EA bits) = 0. I supposed there
might be some reason that PSID is not embedded, I guess the expectation might
be that PSID could be totally independent from the mapping.
Best Regards,
Leaf
From: Maoke [mailto:fib...@gmail.com]
Sent: Thursday, June 28, 2012 3:31 PM
To: Leaf yeh
Cc: Satoru Matsushima; Softwires-wg
Subject: Re: [Softwires] map-00: review on the mode 1:1
2012/6/28 Leaf yeh leaf.y@huawei.com
Maoke - i fully agree with you as zero-lengthed EA-bits is a naturally possible
case of MAP. however, to my understanding, even in this case the Figure 7 of
MAP addressing architecture is still appliable and therefore it implies PSID
length also equals to zero. this is the real meaning of 1:1...
Satoru - Let's think that a CE provisioned with following BMR comes from MAP
DHCPv6 options.
BMR:
o Rule-ipv6-prefix : {exact matched with CE's delegated prefix} o
Rule-ipv4-prefix : x.x.x.x/32
o EA-length : 0
o Port-param option : {PSID/length}
This BMR could be a LW46 provisioning means.
(http://www.ietf.org/mail-archive/web/softwires/current/msg04466.html )
I don't think 'it implies PSID length also equals to zero' can be derived from
'zero-lengthed EA-bits' as per the example from Satoru.
according to MAP architecture of addressing, EA-length MUST not less than the
length of PSID, no matter it is in DHCP configuration or in FMR installed in
BR. see my analysis in the discussion thread with Dec. having a PSID for CE but
no the PSID embedded in the address makes ambiguity when mapping entry is
selected for a specific IPv4 flow.
On the other hand, when the text of '1:1 mode' and '1:1 case' is mentioned in
the draft, I'd like to know what the 1st '1' the 2nd '1' stand for
respectively.
fully agree with you that any 1:1 is confusing. my understanding is 1-IPv6
address : 1-IPv4 address. but the term 1:1 is not necessary to appear in
specification.
- maoke
Best Regards,
Leaf
-Original Message-
From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf
Of Satoru Matsushima
Sent: Thursday, June 28, 2012 1:02 PM
To: Maoke
Cc: Softwires-wg
Subject: Re: [Softwires] map-00: review on the mode 1:1
Hi Maoke-san,
On 2012/06/27, at 20:12, Maoke wrote:
Described text for '1:1 mode' in current version would make some people
confused. We need to make clear for that.
i fully agree with you as zero-lengthed EA-bits is a naturally possible case
of MAP. however, to my understanding, even in this case the Figure 7 of MAP
addressing architecture is still appliable and therefore it implies PSID
length also equals to zero. this is the real meaning of 1:1 that is a natural
case possibly occurs rather than a mode - mode is a sort of preset
configuration. and further, it is not necessary to disable NAT44 in such
EA-null/PSID-null cases at CE.
Right, it isn't a 'mode' which changes any MAP nature.
this definitely makes the MAP spec clear. if necessary, including this
special case in the MAP draft or in the MAP deployment draft, mentioning its
usage, is what i support unless we discover any other flaws regarding this.
Thanks for clarification.
cheers,
--satoru
___
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
2012/6/28 Leaf yeh leaf.y@huawei.com
Maoke - i fully agree with you as zero-lengthed EA-bits is a naturally
possible case of MAP. however, to my understanding, even in this case the
Figure 7 of MAP addressing architecture is still appliable and therefore it
implies PSID length also equals to zero. this is the real meaning of 1:1...
Satoru - Let's think that a CE provisioned with following BMR comes from
MAP DHCPv6 options.
BMR:
o Rule-ipv6-prefix : {exact matched with CE's delegated prefix} o
Rule-ipv4-prefix : x.x.x.x/32
o EA-length : 0
o Port-param option : {PSID/length}
This BMR could be a LW46 provisioning means.
(http://www.ietf.org/mail-archive/web/softwires/current/msg04466.html )
I don't think 'it implies PSID length also equals to zero' can be derived
from 'zero-lengthed EA-bits' as per the example from Satoru.
according to MAP architecture of addressing, EA-length MUST not less than
the length of PSID, no matter it is in DHCP configuration or in FMR
installed in BR. see my analysis in the discussion thread with Dec. having
a PSID for CE but no the PSID embedded in the address makes ambiguity when
mapping entry is selected for a specific IPv4 flow.
On the other hand, when the text of '1:1 mode' and '1:1 case' is mentioned
in the draft, I'd like to know what the 1st '1' the 2nd '1' stand for
respectively.
fully agree with you that any 1:1 is confusing. my understanding is
1-IPv6 address : 1-IPv4 address. but the term 1:1 is not necessary to
appear in specification.
- maoke
Best Regards,
Leaf
-Original Message-
From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On
Behalf Of Satoru Matsushima
Sent: Thursday, June 28, 2012 1:02 PM
To: Maoke
Cc: Softwires-wg
Subject: Re: [Softwires] map-00: review on the mode 1:1
Hi Maoke-san,
On 2012/06/27, at 20:12, Maoke wrote:
Described text for '1:1 mode' in current version would make some people
confused. We need to make clear for that.
i fully agree with you as zero-lengthed EA-bits is a naturally possible
case of MAP. however, to my understanding, even in this case the Figure 7
of MAP addressing architecture is still appliable and therefore it implies
PSID length also equals to zero. this is the real meaning of 1:1 that is a
natural case possibly occurs rather than a mode - mode is a sort of
preset configuration. and further, it is not necessary to disable NAT44 in
such EA-null/PSID-null cases at CE.
Right, it isn't a 'mode' which changes any MAP nature.
this definitely makes the MAP spec clear. if necessary, including this
special case in the MAP draft or in the MAP deployment draft, mentioning
its usage, is what i support unless we discover any other flaws regarding
this.
Thanks for clarification.
cheers,
--satoru
___
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
Hi Woj and Satoru, Thanks for spending time to explain MAP to the ML. It really helps to understand it better. Thanks I concur with Maoke's analysis. If the 1:1 mode means giving the CE a complete IPv4 address (or an IPv4 prefix) in the Rule IPv4 prefix (i.e. EA-bit=0 and r = 32) , this is what MAP allows. If 1:1 means explicitly provisioning PSID in the BR for shared an IPv4 address and PSID isn't contained in the CE MAP address, AFAIK this is not MAP originally designed for. In the current version of the draft, I found two references: MAP can also be provisioned in 1:1 mode. In 1:1 mode the BR has a MAP domain per subscriber, and the CE is configured in hub and spoke mode, with only a DMR and no other mapping rules. This allows for a mode where the BR has one rule per subscriber and the provisioning of IPv4 address or prefix and port sets is independent of the End-User IPv6 prefix. In 1:1 mode, the MAP CE is provisioned with only a Default Mapping Rule, and the full IPv4 address/prefix and port range is provisioned using the DHCP option. When I read them, my interpretation is when EA-bit=0, port-set could be provisioned to CE. BR will also install the BMR+Port-set per CE. It seems to me the 1:1 is the second case rather than first case. Am I reading the draft wrong? I also have a question about routing the packet to CE. If EA-bit=0, does this require each CE will have a different Rule IPv6 prefix (i.e. Each sub is in its domain)? If not, how does routing work in BR? Thanks, Yiu smime.p7s Description: S/MIME cryptographic signature ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] map-00: review on the mode 1:1
On 28.06.2012 14:17, Lee, Yiu wrote: Hi Woj and Satoru, Thanks for spending time to explain MAP to the ML. It really helps to understand it better. Thanks I concur with Maoke's analysis. If the 1:1 mode means giving the CE a complete IPv4 address (or an IPv4 prefix) in the Rule IPv4 prefix (i.e. EA-bit=0 and r = 32) , this is what MAP allows. If 1:1 means explicitly provisioning PSID in the BR for shared an IPv4 address and PSID isn't contained in the CE MAP address, AFAIK this is not MAP originally designed for. In the current version of the draft, I found two references: Sorry for interrupting, but which current version do you referring to? There is softwire-map-01 published earlier today with the 1:1 mode removed. Cheers, Tomek ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] map-00: review on the mode 1:1
I didn't check there was a newer version. My bad. On 6/28/12 9:28 AM, Tomek Mrugalski tomasz.mrugal...@gmail.com wrote: On 28.06.2012 14:17, Lee, Yiu wrote: Hi Woj and Satoru, Thanks for spending time to explain MAP to the ML. It really helps to understand it better. Thanks I concur with Maoke's analysis. If the 1:1 mode means giving the CE a complete IPv4 address (or an IPv4 prefix) in the Rule IPv4 prefix (i.e. EA-bit=0 and r = 32) , this is what MAP allows. If 1:1 means explicitly provisioning PSID in the BR for shared an IPv4 address and PSID isn't contained in the CE MAP address, AFAIK this is not MAP originally designed for. In the current version of the draft, I found two references: Sorry for interrupting, but which current version do you referring to? There is softwire-map-01 published earlier today with the 1:1 mode removed. Cheers, Tomek ___ 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] map-00: review on the mode 1:1
hi Woj,
thanks a lot for the clarification.
2012/6/27 Wojciech Dec wdec.i...@gmail.com
Hi Maoke,
inline...
On 27 June 2012 05:28, Maoke fib...@gmail.com wrote:
hi dear authors,
as the map-00 draft contains the normative 1:1 mode statement that is new
in comparison to the previous versions, i'd like to ask some technical
questions in order to clarify the understanding.
Section 4. page 9:
MAP can also be provisioned in 1:1 mode. In 1:1 mode the BR has a
MAP domain per subscriber, and the CE is configured in hub and spoke
mode, with only a DMR and no other mapping rules. This allows for a
mode where the BR has one rule per subscriber and the provisioning of
IPv4 address or prefix and port sets is independent of the End-User
IPv6 prefix.
Question #1: who is a subscriber? the definition is missing. and
relatedly, what is the protocol for the subscription? the specification on
the protocol is missing too.
Answer 1: Subscriber = MAP CE. We will clarify the term.
got it.
Question #2: what is the relationship between 1:1 mode, encapsulation
mode, translation mode, hubspoke mode, mesh mode? are they independent to
each other, exclusively or not, somehow orthogonal or not? the
specification on the mode is missing.
Answer 2: mode = forwarding mode, also known as transport mode. There are
two of these, translation and encapsulation. No relation between the rest
of the things you mention
okay. then please clearly revise the wording to avoid confusing the
readers. only after the terms/wordings are revised, the MAP deployment is
able to follow these well-defined words and terms.
Question #3: what is the resource for deployment of a MAP domain? the
MAP spec never define that. however, we kept understanding that the
resource for a MAP domain includes:
- an IPv4 prefix (with prefix length 32 or less) shared by
CEs in this domain
- an IPv6 prefix (with prefix length 64 or less) delegated
to the CEs in this domain with a /64 (or shorter) per CE (as the basic
model of prefix d
the newly introduced 1:1 mode obviously abandons this
understanding, then an explicit definition on the resource of a MAP
domain is requested. this is the origin and essential starting point of
the MAP deployment.
Answer 3: What do you mean by resource for deployment?? It has, and always
has been an IPv6 prefix and an IPv4 address. This is the same in *all* of
this solution space. The split in terms of how one arrives at the IPv4
address and port-range has always been variable in MAP.
Additional point: There is no newly introduced 1:1 mode, as the spec
hasn't changed. Folks who implemented according to the previous spec, whihc
you seem to indicate had no 1:1 mode see no difference.
as you clarified CE = subscriber, it is ok. but a new question:
question #3.1: in the 1:1 mode, how long the PSID is? how long the EA-bits?
i understand the bit relationship described in the Figure 7 is the native
property of the MAP algorithm. but it looks to me that 1:1 mode has nothing
related to this figure. it breaks the relation o = p + q. it is hard to
accept that the 1:1 mode is not newly introduced alien. even an alien were
welcome, i would like to suggest the authors prepare a text at Figure 7
stating this is nosense to the 1:1 mode.
question #3.2: then about the rule, for ONE rule, i see only, in Section 5:
* Rule IPv6 prefix (including prefix length)
* Rule IPv4 prefix (including prefix length)
* Rule EA-bits length (in bits)
* Rule Port Parameters (optional)
(as the 5th forwarding mode has been confirmed as a domain configuration)
i don't see there is a PSID value in this tuple, nor i see it in the
example in Sec 5.2, 5.3 for the Given rules.
if Section 5 is not applied to the 1:1 mode, an explicit text This section
is nonsense to the 1:1 mode is required. if a PSID value is to be added
into the rule, i understand it is hard to call not newly introduced
stuff.
Disabling the 1:1 mode would actually require a spec change.
Section 5. page 10:
* Forwarding mode
Question #4: this appears twice at the definition of BMR and DMR,
respectively. though Wojieich and Remi has discussed that in another
thread, i would like to confirm: is this mode a domain configuration
parameter or a rule parameter?
Answer 4: Confirmed, intent is for it to be per domain.
Question #5: does this forwarding mode is a enumerate type of {MAP-T,
MAP-E, 1:1, hubspoke, mesh} or else, e.g., {MAP-T, MAP-E} x {1:1, N:1} x
{hubspoke, mesh}, where the x is the operator for de Cartesian product
of sets? (related to #2)
Answer 5: No need to enumerate, because there is no relation between these
(answered above)
question #5.1: do you mean, for example, when i decided the domain forward
mode, e.g. MAP-T, it is fine that i deploy 1:1 for CE.A while N:1 for CE.B,
right? please confirm this.
Section 7.1 page 19:
In 1:1 mode, the MAP CE is provisioned with
Re: [Softwires] map-00: review on the mode 1:1
Hello Maoke, inline... On 27 June 2012 12:55, Maoke fib...@gmail.com wrote: hi Woj, thanks a lot for the clarification. 2012/6/27 Wojciech Dec wdec.i...@gmail.com Hi Maoke, inline... On 27 June 2012 05:28, Maoke fib...@gmail.com wrote: hi dear authors, as the map-00 draft contains the normative 1:1 mode statement that is new in comparison to the previous versions, i'd like to ask some technical questions in order to clarify the understanding. Section 4. page 9: MAP can also be provisioned in 1:1 mode. In 1:1 mode the BR has a MAP domain per subscriber, and the CE is configured in hub and spoke mode, with only a DMR and no other mapping rules. This allows for a mode where the BR has one rule per subscriber and the provisioning of IPv4 address or prefix and port sets is independent of the End-User IPv6 prefix. Question #1: who is a subscriber? the definition is missing. and relatedly, what is the protocol for the subscription? the specification on the protocol is missing too. Answer 1: Subscriber = MAP CE. We will clarify the term. got it. Question #2: what is the relationship between 1:1 mode, encapsulation mode, translation mode, hubspoke mode, mesh mode? are they independent to each other, exclusively or not, somehow orthogonal or not? the specification on the mode is missing. Answer 2: mode = forwarding mode, also known as transport mode. There are two of these, translation and encapsulation. No relation between the rest of the things you mention okay. then please clearly revise the wording to avoid confusing the readers. only after the terms/wordings are revised, the MAP deployment is able to follow these well-defined words and terms. Question #3: what is the resource for deployment of a MAP domain? the MAP spec never define that. however, we kept understanding that the resource for a MAP domain includes: - an IPv4 prefix (with prefix length 32 or less) shared by CEs in this domain - an IPv6 prefix (with prefix length 64 or less) delegated to the CEs in this domain with a /64 (or shorter) per CE (as the basic model of prefix d the newly introduced 1:1 mode obviously abandons this understanding, then an explicit definition on the resource of a MAP domain is requested. this is the origin and essential starting point of the MAP deployment. Answer 3: What do you mean by resource for deployment?? It has, and always has been an IPv6 prefix and an IPv4 address. This is the same in *all* of this solution space. The split in terms of how one arrives at the IPv4 address and port-range has always been variable in MAP. Additional point: There is no newly introduced 1:1 mode, as the spec hasn't changed. Folks who implemented according to the previous spec, whihc you seem to indicate had no 1:1 mode see no difference. as you clarified CE = subscriber, it is ok. but a new question: question #3.1: in the 1:1 mode, how long the PSID is? how long the EA-bits? i understand the bit relationship described in the Figure 7 is the native property of the MAP algorithm. but it looks to me that 1:1 mode has nothing related to this figure. it breaks the relation o = p + q. it is hard to accept that the 1:1 mode is not newly introduced alien. even an alien were welcome, i would like to suggest the authors prepare a text at Figure 7 stating this is nosense to the 1:1 mode. The relation of o = p + q holds, for all values of p and q giving 0 = o =48. Given that we have resticted MAP to positive values of p and q, although negative were suggested, that provides you the range of p and q. question #3.2: then about the rule, for ONE rule, i see only, in Section 5: * Rule IPv6 prefix (including prefix length) * Rule IPv4 prefix (including prefix length) * Rule EA-bits length (in bits) * Rule Port Parameters (optional) (as the 5th forwarding mode has been confirmed as a domain configuration) i don't see there is a PSID value in this tuple, nor i see it in the example in Sec 5.2, 5.3 for the Given rules. Well, if you look at the info list passed in an FMR you will see that everything is there allowing the derivation of a PSID for a given destination if/when needed and/or the port range from a given FMR. In the case of EA=0, the prefix is enough for forwarding. if Section 5 is not applied to the 1:1 mode, an explicit text This section is nonsense to the 1:1 mode is required. if a PSID value is to be added into the rule, i understand it is hard to call not newly introduced stuff. As explained, it is not :-) And again, I bring your attention to what several implementers said about this, all of whom used previous drafts as their spec. Disabling the 1:1 mode would actually require a spec change. Section 5. page 10: * Forwarding mode Question #4: this appears twice at the definition of BMR and DMR, respectively. though Wojieich and Remi has discussed that in another thread,
Re: [Softwires] map-00: review on the mode 1:1
hi Woj, thanks but it looks you didn't answer my questions somewhere maybe because my questions were not clearly expressed. ;-) inline.. 2012/6/27 Wojciech Dec wdec.i...@gmail.com Hello Maoke, inline... On 27 June 2012 12:55, Maoke fib...@gmail.com wrote: hi Woj, thanks a lot for the clarification. 2012/6/27 Wojciech Dec wdec.i...@gmail.com Hi Maoke, inline... On 27 June 2012 05:28, Maoke fib...@gmail.com wrote: hi dear authors, as the map-00 draft contains the normative 1:1 mode statement that is new in comparison to the previous versions, i'd like to ask some technical questions in order to clarify the understanding. Section 4. page 9: MAP can also be provisioned in 1:1 mode. In 1:1 mode the BR has a MAP domain per subscriber, and the CE is configured in hub and spoke mode, with only a DMR and no other mapping rules. This allows for a mode where the BR has one rule per subscriber and the provisioning of IPv4 address or prefix and port sets is independent of the End-User IPv6 prefix. Question #1: who is a subscriber? the definition is missing. and relatedly, what is the protocol for the subscription? the specification on the protocol is missing too. Answer 1: Subscriber = MAP CE. We will clarify the term. got it. Question #2: what is the relationship between 1:1 mode, encapsulation mode, translation mode, hubspoke mode, mesh mode? are they independent to each other, exclusively or not, somehow orthogonal or not? the specification on the mode is missing. Answer 2: mode = forwarding mode, also known as transport mode. There are two of these, translation and encapsulation. No relation between the rest of the things you mention okay. then please clearly revise the wording to avoid confusing the readers. only after the terms/wordings are revised, the MAP deployment is able to follow these well-defined words and terms. Question #3: what is the resource for deployment of a MAP domain? the MAP spec never define that. however, we kept understanding that the resource for a MAP domain includes: - an IPv4 prefix (with prefix length 32 or less) shared by CEs in this domain - an IPv6 prefix (with prefix length 64 or less) delegated to the CEs in this domain with a /64 (or shorter) per CE (as the basic model of prefix d the newly introduced 1:1 mode obviously abandons this understanding, then an explicit definition on the resource of a MAP domain is requested. this is the origin and essential starting point of the MAP deployment. Answer 3: What do you mean by resource for deployment?? It has, and always has been an IPv6 prefix and an IPv4 address. This is the same in *all* of this solution space. The split in terms of how one arrives at the IPv4 address and port-range has always been variable in MAP. Additional point: There is no newly introduced 1:1 mode, as the spec hasn't changed. Folks who implemented according to the previous spec, whihc you seem to indicate had no 1:1 mode see no difference. as you clarified CE = subscriber, it is ok. but a new question: question #3.1: in the 1:1 mode, how long the PSID is? how long the EA-bits? i understand the bit relationship described in the Figure 7 is the native property of the MAP algorithm. but it looks to me that 1:1 mode has nothing related to this figure. it breaks the relation o = p + q. it is hard to accept that the 1:1 mode is not newly introduced alien. even an alien were welcome, i would like to suggest the authors prepare a text at Figure 7 stating this is nosense to the 1:1 mode. The relation of o = p + q holds, for all values of p and q giving 0 = o =48. Given that we have resticted MAP to positive values of p and q, although negative were suggested, that provides you the range of p and q. then there are two possible understanding to the 1:1 case: A. EA-bit becomes zero (it is surely not excluded by the MAP architecture), o = 0 = p = q = 0. p = 0 means the whole IPv4 address (/32) is applied in the mapping algorithm, with no any bits remained in the generated IPv6 address. q = 0 means the PSID length is zero, and therefore the CE working with such an mapping rule has a (full) IPv4 address without sharing to any others. B. CE works with a shared or not shared IPv4 address while it is considered that the CE is set to work in 1:1 mode. if shared, there IS a PSID assigned to the CE but (artificially) not inserted into the MAP IPv6 address for the CE. if your 1:1 mode means A, it is fine and i totally agree that it is a naturally established case of the MAP; if your 1:1 mode means B, i must say the MAP addressing algorithm is abandoned for this special mode de facto. i understand current MAP is talking B. please confirm! up to now, my understanding is: containing the explanation on A and clarifying its use case would make MAP spec comprehensive, while containing the text meaning B makes MAP spec a low-quality
Re: [Softwires] map-00: review on the mode 1:1
Hi Maoke-san, On 2012/06/27, at 20:12, Maoke wrote: Described text for '1:1 mode' in current version would make some people confused. We need to make clear for that. i fully agree with you as zero-lengthed EA-bits is a naturally possible case of MAP. however, to my understanding, even in this case the Figure 7 of MAP addressing architecture is still appliable and therefore it implies PSID length also equals to zero. this is the real meaning of 1:1 that is a natural case possibly occurs rather than a mode - mode is a sort of preset configuration. and further, it is not necessary to disable NAT44 in such EA-null/PSID-null cases at CE. Right, it isn't a 'mode' which changes any MAP nature. this definitely makes the MAP spec clear. if necessary, including this special case in the MAP draft or in the MAP deployment draft, mentioning its usage, is what i support unless we discover any other flaws regarding this. Thanks for clarification. cheers, --satoru ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
