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 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. 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-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 > _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
