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
