Tom, to state it another way. I don't want rewrite section 5, unless there is a clear benefit in doing so. I'm not against better text of course, and if you want to propose an alternative section 5, then the working group can decide which version they want.
cheers, Ole On Feb 25, 2013, at 13:56 , Tom Taylor <[email protected]> wrote: > I really didn't expect this argument. These are not use cases; they are the > procedures necessary to calculate the bits that go on the wire due to the > complexity of the MAP formulation. Take a look at the code being implemented > in your routers and you will see similar branches in logic or variations on > them. What would go into a deployment document would be how to apply these > different formulations to particular network situations. > > Tom > > On 25/02/2013 4:51 AM, Ole Troan wrote: >> Tom, et, al, >> >> thanks for the suggestion. I would lean towards pushing back on rewriting >> section 5, on the grounds >> that this is a set of generic tools and that specific use cases rather could >> go in a deployment document. >> >> does anyone else have strong opinions on current text versus Tom's proposed >> changes? >> >> cheers, >> Ole >> >> On Feb 21, 2013, at 16:43 , Tom Taylor <[email protected]> wrote: >> >>> The two bullets below were actually a "Trojan Horse" of sorts. They set the >>> agenda for Sections 5.2 and 5.3 respectively. I think those two sections >>> should have different titles to start with: >>> >>> 5.2 Provisioning the MAP IPv4 Address, MAP IPv6 Address, and Port Set >>> Identifier (PSID) At a CE >>> >>> 5.2.1 Deriving the IPv4 Address and PSID From the End-User IPv6 Prefix and >>> the Basic Mapping Rule >>> >>> 5.2.2 Deriving the IPv6 Address To Use On the MAP Interface >>> >>> 5.3 Deriving the MAP IPv6 Address From the IPv4 Address and Port and the >>> Matching Forwarding Mapping Rule (Mesh Mode Only) >>> >>> The procedure described in each section should then match the title. I'll >>> sketch the flow here, but I can supply detailed text if desired. >>> >>> >>> 5.2.1 Deriving the IPv4 Address and PSID From the End-User IPv6 Prefix and >>> the Basic Mapping Rule >>> >>> - distinguishing the Basic Mapping Rule (BMR) from other mapping rules that >>> are provisioned >>> >>> - locating the Extended Address (EA) bits in the End-User IPv6 Prefix >>> >>> - Case 1: Port set identifier (PSID) is explicitly provisioned separately >>> from the BMR >>> -- IPv4 address is shared >>> -- IPv4 address is the concatenation of the IPv4 prefix provided in the BMR >>> and the IPv4 suffix provided by the EA bits >>> -- if the result is not a /32, error >>> >>> - Case 2: PSID is embedded in the EA bits >>> -- true if the sum (o + r) is greater than 32, where o is the number of EA >>> bits as indicated by the BMR, and r is the length of the IPv4 prefix >>> supplied by the BMR >>> -- shared IPv4 address is the concatenation of the IPv4 prefix supplied by >>> the BMR and as many of the high-order bits within the EA bit field as >>> required to make up a /32 >>> -- PSID is given by the remaining lower-order bits in the EA bit field >>> >>> - Case 3: non-shared IPv4 address or prefix >>> -- true if the sum (o + r) as defined above is less than or equal to 32 >>> -- IPv4 address or prefix is equal to the concatenation of the IPv4 prefix >>> as supplied by the BMR with the entire contents of the EA bit field. >>> >>> 5.2.2 Deriving the IPv6 Address To Use On the MAP Interface >>> >>> - MAP IPv6 address is given by the concatenation of the provisioned >>> End-User IPv6 Prefix with an interface identifier derived as described in >>> Section 6. >>> >>> - this applies for both hub-and-spoke and mesh mode >>> >>> 5.3 Deriving the MAP IPv6 Address From the Destination IPv4 Address and >>> Port and the Matching Forwarding Mapping Rule (Mesh Mode Only) >>> >>> - locate the applicable Mapping Rule by longest match on rule IPv4 >>> address/prefix >>> >>> - Derive the target End-User IPv6 prefix less the subnet identifier as >>> follows: >>> >>> -- Case 1: length of the EA field as given by the selected Mapping Rule is 0 >>> --- target End-User IPv6 prefix (less the subnet identifier) is equal to >>> the IPv6 prefix provided by the selected Mapping Rule >>> >>> -- Case 2: sum (o + r) is less than or equal to 32, where o and r are as >>> defined in Section 5.2 >>> --- implies destination IPv4 address/prefix is dedicated to destination CE >>> --- EA bit field is equal to the highest-order o bits of the destination >>> IPv4 address not contained in the IPv4 address/prefix provided by the >>> selected Mapping Rule >>> --- target End-User IPv6 prefix (less the subnet identifier) is equal to >>> the IPv6 prefix provided by the selected Mapping Rule followed in >>> concatenation with the derived EA bit field >>> >>> -- Case 3: sum (o + r) as defined above is greater than 32 >>> --- implies destination IPv4 address/prefix is shared >>> --- set the high-order portion of the EA bit field equal to the low-order >>> (32 - r) bits of the destination IPv4 address >>> --- the remaining o - (32 - r) bits of the EA bit field are equal to the >>> high-order bits of the destination port number, beginning with the bit >>> after the offset given by the selected Mapping Rule (default = 6) >>> --- target End-User IPv6 prefix (less the subnet identifier) is equal to >>> the IPv6 prefix provided by the selected Mapping Rule followed in >>> concatenation with the derived EA bit field >>> >>> - subnet identifier portion of the End-User IPv6 prefix is all zeroes >>> >>> - End-User MAP Address is equal to the End-User IPv6 prefix concatenated >>> with an interface identifier (IID) derived as described in Section 6. >>> >>> Tom Taylor >>> >>> >>> On 13/02/2013 3:07 AM, Ole Troan wrote: >>>> I agree with Tom's proposed changes. >>>> I'll put them in a upcoming revision 05, if no-one objects. >>>> (I still think we can do a WGLC on revision 04). >>>> >>>> cheers, >>>> Ole >>>> >>>> >>>>> Remark: I'm not sure the two bullets (quoted further down) tell the full >>>>> story as they stand. I propose to modify them as follows: >>>>> >>>>> 1. Basic Mapping Rule (BMR) - mandatory. There can only be one >>>>> Basic Mapping Rule per End-user IPv6 prefix. In combination >>>>> with the End-user IPv6 prefix, the Basic Mapping Rule is used >>>>> to derive the IPv4 prefix, address, or shared address and >>>>> the PSID assigned to the CE. >>>>> >>>>> 2. Forwarding Mapping Rule (FMR) - optional, used for forwarding. >>>>> The Basic Mapping Rule is also a Forwarding Mapping Rule. Each >>>>> Forwarding Mapping Rule will result in an entry in the Rules >>>>> table for the Rule IPv4 prefix. Given a destination IPv4 address >>>>> and port within the MAP domain, a MAP node can use the matching >>>>> FMR to derive the End-user IPv6 address of the interface through >>>>> which that destination address-port combination can be reached. >>>>> >>>>> >>>>> On 12/02/2013 9:22 AM, Ole Troan wrote: >>>>>> Tom, >>>>>> >>>>>>> Thanks. What about the assertions in the bullets? >>>>>> >>>>>> sorry, may be my short term memory... what do you mean? >>>>>> >>>>>> cheers, >>>>>> Ole >>>>>> >>>>>> >>>>>>> >>>>>>> On 12/02/2013 3:27 AM, Ole Troan wrote: >>>>>>>> Tom, >>>>>>>> >>>>>>>>> I'm still hoping to see a response to this. >>>>>>>>> >>>>>>>>> On 06/02/2013 8:42 AM, Tom Taylor wrote: >>>>>>>>>> Section 5 of the latest version of MAP has the following: >>>>>>>>>> >>>>>>>>>> 1. Basic Mapping Rule (BMR) - mandatory, used for IPv4 prefix, >>>>>>>>>> address or port set assignment. There can only be one Basic >>>>>>>>>> Mapping Rule per End-user IPv6 prefix. The Basic Mapping >>>>>>>>>> Rule is >>>>>>>>>> used to configure the MAP IPv6 address or prefix. >>>>>>>>>> >>>>>>>>>> 2. Forwarding Mapping Rule (FMR) - optional, used for forwarding. >>>>>>>>>> The Basic Mapping Rule is also a Forwarding Mapping Rule. >>>>>>>>>> Each >>>>>>>>>> Forwarding Mapping Rule will result in an entry in the Rules >>>>>>>>>> table for the Rule IPv4 prefix. >>>>>>>>>> >>>>>>>>>> Question: there will always be a BMR. In the absence of additional >>>>>>>>>> rules, how does a CE know whether it can use the BMR for forwarding >>>>>>>>>> or >>>>>>>>>> must always use the default rule? >>>>>>>> >>>>>>>> the answer to that is in section 7, last bullet. >>>>>>>> >>>>>>>> that is, the MAP CE must be configured to be in hub and spoke mode or >>>>>>>> mesh mode. >>>>>>>> which mode it is in decided if the BMR is used for forwarding or not. >>>>>>>> >>>>>>>> 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 _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
