Woj, According to your description, it is clear that the way to deal with EA=0 is quite different with EA>0. 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 EA>0 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-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> >>> >> 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 > > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * ===============================================
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
