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

Reply via email to