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.com<mailto:fib...@gmail.com>> wrote: 2012/7/26 <mohamed.boucad...@orange.com<mailto: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> >[mailto: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-bit>0 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<mailto: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<mailto: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<mailto:Softwires@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/softwires >>> > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org<mailto:Softwires@ietf.org> >https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ Softwires mailing list Softwires@ietf.org<mailto:Softwires@ietf.org> https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list Softwires@ietf.org<mailto:Softwires@ietf.org> https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
