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 <[email protected]> Date: Friday, July 27, 2012 8:06 AM To: "Yiu L. LEE" <[email protected]> Cc: Ole Trøan <[email protected]>, Softwires-wg <[email protected]> Subject: Re: [Softwires] map-00: review on the mode 1:1 On 26 July 2012 16:59, Lee, Yiu <[email protected]> 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" <[email protected]> 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" <[email protected]> >>> >> 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" <[email protected]> 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 >>>>> >>>> [email protected] >>>>> >>>> https://www.ietf.org/mailman/listinfo/softwires >>>> >>> >> > > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
