Subject: [Softwires] MAP-04: BMR and forwarding rules

From: Tom Taylor <[email-masked]>
Date: Wed, 06 Feb 2013 08:42:41 -0500

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?

Remark: I'm not sure these two bullets 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 MAP IPv6 address of the interface through
        which that destination address-port combination can be reached.

Tom Taylor

---

From: Tom Taylor <[email-masked]>
Date: Mon, 11 Feb 2013 21:43:45 -0500

I'm still hoping to see a response to this.

---

From: Ole Troan <[email-masked]>
Date: Tue, 12 Feb 2013 09:27:46 +0100

Tom,

>> 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

---

From: Tom Taylor <[email-masked]>
Date: Tue, 12 Feb 2013 09:17:41 -0500

Thanks. What about the assertions in the bullets?

---

From: Ole Troan <[email-masked]>
Date: Tue, 12 Feb 2013 15:22:15 +0100

Tom,

> Thanks. What about the assertions in the bullets?

sorry, may be my short term memory... what do you mean?

cheers,
Ole

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 12 Feb 2013 18:05:36 +0100

Well, actually on this topic I think it may make sense at least from a
terminology consistency perspective to go back to calling out the Default
Mapping Rule (DMR) and, just like the BMR, marking it as mandatory. That's
what actually is already in the DHCP draft.

Regards,
Woj.

On 12 February 2013 15:22, Ole Troan <[email-masked]> wrote:

> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: Tom Taylor <[email-masked]>
Date: Tue, 12 Feb 2013 20:14:17 -0500

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:

        FMR to derive the End-user IPv6 address of the interface through

---

From: Ole Troan <[email-masked]>
Date: Wed, 13 Feb 2013 09:07:19 +0100

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:
>

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 13 Feb 2013 11:13:48 +0100

Fine with that, but can we also go back to calling out the DMR which gives
consistency in terms along with BMR and FMR?

Thanks,
Woj.

---

From: <[email-masked]>
Date: Wed, 13 Feb 2013 17:51:57 +0100

Hi Ole, all,

Before initiating a WGLC for this document, I guess there is a pending discussion point: what to do with MAP1:1 mode. 

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] 
>[mailto:[email-masked]] De la part de Ole Troan
>Envoyé : mercredi 13 février 2013 09:07
>À : Tom Taylor
>Cc : Softwires
>Objet : Re: [Softwires] MAP-04: BMR and forwarding rules
>
>> 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:
>>

---

From: Ole Troan <[email-masked]>
Date: Wed, 13 Feb 2013 19:23:11 +0100

Med,

> Before initiating a WGLC for this document, I guess there is a pending discussion point: what to do with MAP1:1 mode. 

do we really...? :-)
if you have changes to propose to the document, can you suggest text?

cheers,
Ole

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 13 Feb 2013 16:38:06 -0500

Med,

> Before initiating a WGLC for this document, I guess there is a pending discussion point: what to do with MAP1:1 mode. 

Can you open an issue in the tracker for this please. We can try to
discuss this on the list to converge on a decision, failing which we can
take it up during the meeting.

Thanks
Suresh

---

From: Ole Troan <[email-masked]>
Date: Wed, 13 Feb 2013 22:48:16 +0100

> take it up during the meeting.

in the context of the MAP-E draft I have to admit that I don't understand what the issue is, nor what there is to discuss.
could someone fill me in?

cheers,
Ole

---

From: Tom Taylor <[email-masked]>
Date: Wed, 13 Feb 2013 17:57:22 -0500

I know that my own feeling is that MAP-E as currently described has a 
split personality. On the one hand, there are those algorithms in 
support of address sharing. On the other hand, there is provision for 
doing without the algorithms (especially when o=0), in which case 
ordinary provisioning processes would be sufficient.

I think we can all agree that during IPv6 transition operators need both 
address sharing and the ability to provide full IPv4 addresses. The 
question is whether it is necessary to combine both in this 
specification. The one justification I could see would be to provide the 
associated forwarding rules to CEs with shared addresses in the full 
mesh case. Is there another justification?

Tom

---

From: Ole Troan <[email-masked]>
Date: Thu, 14 Feb 2013 00:17:58 +0100

> I know that my own feeling is that MAP-E as currently described has a split personality. On the one hand, there are those algorithms in support of address sharing. On the other hand, there is provision for doing without the algorithms (especially when o=0), in which case ordinary provisioning processes would be sufficient.
> 
> I think we can all agree that during IPv6 transition operators need both address sharing and the ability to provide full IPv4 addresses. The question is whether it is necessary to combine both in this specification. The one justification I could see would be to provide the associated forwarding rules to CEs with shared addresses in the full mesh case. Is there another justification?

MAP-E is a generic tool.
how an operator choose to use mapping rules is a deployment choice.

cheers,
Ole

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 14 Feb 2013 15:22:57 +0000

I thought we had closed this optic after the extensive discussion on the
mailing list few months back.

Cheers,
Rajiv

-----Original Message-----
From: Ole Troan <[email-masked]>
Date: Wednesday, February 13, 2013 6:17 PM
To: Tom Taylor <[email-masked]>
Cc: Softwires-wg list <[email-masked]>
Subject: Re: [Softwires] MAP-04: BMR and forwarding rules

>> I think we can all agree that during IPv6 transition operators need
>>both address sharing and the ability to provide full IPv4 addresses. The

---

From: Tom Taylor <[email-masked]>
Date: Thu, 21 Feb 2013 10:43:36 -0500

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

---

From: Tom Taylor <[email-masked]>
Date: Thu, 21 Feb 2013 22:37:29 -0500

I forgot that the border router has to use the procedure of section 5.3 
in both mesh and hub-and-spoke mode. So "(Mesh Mode Only)" should be 
removed from the title of the section, but introductory text should say 
that the procedure is used by CEs in mesh mode only, but by the border 
router in all cases.

On 21/02/2013 10:43 AM, Tom Taylor wrote:
>>> 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:
>>>

---

From: Ole Troan <[email-masked]>
Date: Mon, 25 Feb 2013 10:51:07 +0100

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-masked]> 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.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
> 
> - Case 1: Port set identifier (PSID) is explicitly provisioned separately from the BMR
> -- IPv4 address is the concatenation of the IPv4 prefix provided in the BMR and the IPv4 suffix provided by 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
> -- 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.
> 
> - 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.
> 
> 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:
> 
> --- 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
> --- 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
> 
> --- 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
> 
> - 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
> 
>

---

From: Tom Taylor <[email-masked]>
Date: Mon, 25 Feb 2013 07:56:22 -0500

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

---

From: Ole Troan <[email-masked]>
Date: Mon, 25 Feb 2013 14:17:23 +0100

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-masked]> 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
>

---

From: Tom Taylor <[email-masked]>
Date: Mon, 25 Feb 2013 10:05:43 -0500

OK, I await the WG's verdict.

> can decide which version they want.
...