Subject: [Softwires] MAP-E 1:1 for HA

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 9 Nov 2012 19:43:08 +0000

I have a question for the HA design concept of MAP-E 1:1. The central theme
of MAP-E is to make BR as stateless as possible and use Anycast address to
identify the MAP-E BR. However, if we use MAP-E 1:1 mode, the operator must
have to pre-provision all the subscribe rules to all the BRs sharing the
same Anycast address for reliable HA. This requires operators to carefully
plan out which BRs support which subscribers. It is because BR is
"per-subscriber stateful" in MAP-E 1:1 mode. Compared to the MAP-E design,
HA in MAP-E only requires the operators to use the same set of rules to
cover the entire domain. IMHO, this contradicts  the original spirit of
stateless solution and always puzzles me why MAP-E 1:1 bears the MAP-E name.
MAP-E and 1:1 MAP-E are two completely different solutions and target to
different deployment scenarios. I would love to hear others to comment in
the ML how to resolve this issue.

Thanks,
Yiu

---

From: Ole Trøan <[email-masked]>
Date: Fri, 9 Nov 2012 20:41:23 -0500

Yiu,

> I have a question for the HA design concept of MAP-E 1:1. The central theme of MAP-E is to make BR as stateless as possible and use Anycast address to identify the MAP-E BR. However, if we use MAP-E 1:1 mode, the operator must have to pre-provision all the subscribe rules to all the BRs sharing the same Anycast address for reliable HA. This requires operators to carefully plan out which BRs support which subscribers. It is because BR is "per-subscriber stateful" in MAP-E 1:1 mode. Compared to the MAP-E design, HA in MAP-E only requires the operators to use the same set of rules to cover the entire domain. IMHO, this contradicts  the original spirit of stateless solution and always puzzles me why MAP-E 1:1 bears the MAP-E name. MAP-E and 1:1 MAP-E are two completely different solutions and target to different deployment scenarios. I would love to hear others to comment in the ML how to resolve this issue.

all nodes in a MAP domain must have the same rules.
in 1:1 mode there is only the CE and the BR in the domain.

having an aggregate route e.g. an IPv4 /24 or a host route a /32 doesn't mean you need a different RIB implementation.
a host route which is what we have in 1:1 mode is just a corner case. what is "completely different" about it?

cheers,
Ole

---

From: Satoru Matsushima <[email-masked]>
Date: Fri, 9 Nov 2012 21:54:35 -0500

On 2012/11/09, at 20:41, Ole Trøan <[email-masked]> wrote:
--snip--
>> IMHO, this contradicts  the original spirit of stateless solution and always puzzles me why MAP-E 1:1 bears the MAP-E name. MAP-E and 1:1 MAP-E are two completely different solutions and target to different deployment scenarios. I would love to hear others to comment in the ML how to resolve this issue.
> 

+1. It is consistent with IP networking principle.

BTW, to just clarify about map domain, cited from map-02 draft:

> 3.  Terminology
> 
> 
>    MAP domain:             One or more MAP CEs and BRs connected to the
>                            same virtual link.  A service provider may
>                            deploy a single MAP domain, or may utilize
>                            multiple MAP domains.
> 

cheers,
--satoru

---

From: Qiong <[email-masked]>
Date: Sat, 10 Nov 2012 12:05:04 +0800

Hi Ole,

On Sat, Nov 10, 2012 at 9:41 AM, Ole Trøan <[email-masked]> wrote:

> Yiu,
>
> > I have a question for the HA design concept of MAP-E 1:1. The central
> theme of MAP-E is to make BR as stateless as possible and use Anycast
> address to identify the MAP-E BR. However, if we use MAP-E 1:1 mode, the
> operator must have to pre-provision all the subscribe rules to all the BRs
> sharing the same Anycast address for reliable HA. This requires operators
> to carefully plan out which BRs support which subscribers. It is because BR
> is "per-subscriber stateful" in MAP-E 1:1 mode. Compared to the MAP-E
> design, HA in MAP-E only requires the operators to use the same set of
> rules to cover the entire domain. IMHO, this contradicts  the original
> spirit of stateless solution and always puzzles me why MAP-E 1:1 bears the
> MAP-E name. MAP-E and 1:1 MAP-E are two completely different solutions and
> target to different deployment scenarios. I would love to hear others to
> comment in the ML how to resolve this issue.
>
> having an aggregate route e.g. an IPv4 /24 or a host route a /32 doesn't
> mean you need a different RIB implementation.
>
[Qiong] Actually, that's not the same. If we only need /32, there is no
need to do LPM implementation anymore, only exact matching is needed and
this is much eaiser than LPM. LPM is not optimized for /32 routing lookup.
The reason that current routers still implement LPM rather not exact
matching is because /32 is a truely corner case in RIB. However, if /32 is
not a corner case, but is the major requirement for operators, I believe
more efficient way should be introduced.

Best wishes
Qiong

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

-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude

Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ *
===============================================

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Sat, 10 Nov 2012 06:34:55 +0000

One can define a MAP-domain consisting of 1 CE or N CEs. This is more of a
deployment choice.

Cheers,
Rajiv

-----Original Message-----
From: <Lee>, Yiu Lee <[email-masked]>
Date: Friday, November 9, 2012 2:43 PM
To: Softwires-wg list <[email-masked]>
Subject: [Softwires] MAP-E 1:1 for HA

>operator must have to pre-provision all
> the subscribe rules to all the BRs sharing the same Anycast address for
>reliable HA. This requires operators to carefully plan out which BRs
>support which subscribers. It is because BR is "per-subscriber stateful"
>in MAP-E 1:1 mode. Compared to the MAP-E design,
>stateless solution and always puzzles me why MAP-E 1:1 bears the MAP-E
>name. MAP-E and 1:1 MAP-E are two completely
> different solutions and target to different deployment scenarios. I
>would love to hear others to comment in the ML how to resolve this issue.
>
>
>Thanks,
>Yiu
>
>
>
>

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Sat, 10 Nov 2012 06:45:04 +0000

Let's not get into debating the local behavior e.g. Implementation
specifics (since one can argue that the router vendors can provide
comparable optimization for host routes as well as non-host routes).

If I as a vendor were really bothered about host vs. non-host
control-plane & data-plane, then I could take the same standard (e.g.
MAP-E) and implement the preferred part with whatever optimization
possible without benefitting the non-preferred part. It really becomes an
implementation (local behavior) choice.

We don't need more of the same thing. :)

Cheers,
Rajiv

-----Original Message-----
From: Qiong <[email-masked]>
Date: Friday, November 9, 2012 11:05 PM
To: Ole Troan <[email-masked]>
Cc: Softwires-wg list <[email-masked]>
Subject: Re: [Softwires] MAP-E 1:1 for HA

>>operator must have to pre-provision all the
> subscribe rules to all the BRs sharing the same Anycast address for
>matching is because /32 is a truely corner case in RIB. However, if /32
>is not a corner case, but is the major requirement for operators, I
>believe more efficient way should be introduced.
>
>Best wishes
>Qiong 
> 
>
>lightweight 4over6: http://sourceforge.net/projects/laft6/
>PCP-natcoord: 
>http://sourceforge.net/projects/pcpportsetdemo/
><http://sourceforge.net/projects/pcpportsetdemo/>

---

From: Qiong <[email-masked]>
Date: Sun, 11 Nov 2012 11:01:00 +0800

Rajiv,

> implementation (local behavior) choice.
Now that you need to optimize the implementation for different
requirements, why not optimize it from protocol level ? So that every
vendor would know how to implement for different requirements, rather than
let operators pushing vendors one by one and tell them how to do.

Without standardization, operators could still ask vendors to implement
whatever they want. But standardization would reflect the common
requirements from operators, and that would be easier for vendors to follow
and implement. I do not understand why we do not follow this efficient way.

Best wishes
Qiong

Open source code:

---

From: Qi Sun <[email-masked]>
Date: Sun, 11 Nov 2012 20:42:27 +0800

Rajiv,

Please see inline.

Thanks,

Qi Sun

> comparable optimization for host routes as well as non-host routes).

[Qi] This is not about implementations. But about the conflicts of two parts in one protocol.
> possible

[Qi]You mean implementing the preferred part with a method that is conflicting with the  base protocol? I don't see a reason why we should do that. 
There is another protocol (e.g. lw4over6) perfectly suitable for the scenario, which is optimized by design. Vendors don't have to waste energy figuring out how to optimize.

> without benefitting the non-preferred part. It really becomes an

---

From: Ole Trøan <[email-masked]>
Date: Sun, 11 Nov 2012 08:11:24 -0500

Qiong,

> Now that you need to optimize the implementation for different requirements, why not optimize it from protocol level ? So that every vendor would know how to implement for different requirements, rather than let operators pushing vendors one by one and tell them how to do.

what is the difference in protocol?
are the bits on the wire between these two proposals different?

cheers,
Ole

---

From: Tom Taylor <[email-masked]>
Date: Mon, 12 Nov 2012 11:16:16 -0500

I'd say they are, in that the IPv6 address for MAP has semantics buried 
in it.

But the really relevant difference between MAP and LW4over6 is the 
latter's requirement for the AFTR to carry and use per-subscriber data. 
That is a fundamental factor in the cost equation. However, the cost of 
the AFTR is only part of the total system cost (including the cost of 
operation and feasibility of deployment), and the tradeoffs for some 
operators will be different from those for others.

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 12 Nov 2012 18:33:06 +0000

I am not talking about whether a MAP-domain should support 1 or N CEs.
What I am trying to say is MAP-E 1:1 requires the BR to know per
subscriber information and the operator must pre-provision per-subscriber
based rules to every BR in the same domain. In addition, the BR can't use
programatic logic to reduce states. When the WG first decided to work on a
"stateless" solution, the goal was to make BR as stateless as possible.
MAP-E 1:1 in contrast requires to store all subscriber rules in the BR and
can't derive the CE's IPv6 address using programatic logic. I found it odd
to include MAP-1 1:1 be part of a stateless solution. MAP-E 1:1 looks a
stateful solution to me.

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 12 Nov 2012 18:35:14 +0000

Ole,

>From my perspective, the argument is not whether two protocols are
identical or not. I found MAP-E 1:1 is a stateful solution. I found it odd
to make it part of MAP-E which was originally decided a stateless solution.

Regards,
Yiu

On 11/11/12 8:11 AM, "Ole Trøan" <[email-masked]> wrote:

>>vendor would know how to implement for different requirements, rather
>>than let operators pushing vendors one by one and tell them how to do.
>

---

From: Ole Trøan <[email-masked]>
Date: Mon, 12 Nov 2012 20:11:04 +0100

Yiu,

> to make it part of MAP-E which was originally decided a stateless solution.

look at it as a slider. just like you can represent both aggregate routes (/20, /24) and host routes (/32) in a RIB,
so you can in MAP.
you can make a data structure that only support host routes (LW46), but when you have a data structure that supports
variable prefix lengths then host route support is part of the package.

I don't think there is a way to take 1:1 mode out of MAP, even if we wanted to.

cheers,
Ole

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 12 Nov 2012 19:51:26 +0000

Sure, and it is really a deployment choice (just like it is a deployment
choice to use a dynamic routing protocol to advertise host routes or
summary routes or both in an IP network). But that's not to say that we
need one protocol for advertising the host routes, and another for
advertising the summary routes.

Cheers,
Rajiv

---

From: Tetsuya Murakami <[email-masked]>
Date: Tue, 13 Nov 2012 02:01:02 +0000

Yiu,

> to include MAP-1 1:1 be part of a stateless solution. MAP-E 1:1 looks a

I am not sure why you are thinking MAP-E 1:1 as the stateful solution. BR just has the configuration (not state). I think the stateless does not mean "no configuration".

Thanks,
Tetsuya

---

From: Tetsuya Murakami <[email-masked]>
Date: Tue, 13 Nov 2012 02:02:38 +0000

> I don't think there is a way to take 1:1 mode out of MAP, even if we wanted to.

+1. The host route (/32) is also part of the variable prefix length. 

Thanks,
Tetsuya

---

From: Qiong <[email-masked]>
Date: Tue, 13 Nov 2012 11:54:49 +0800

Ole,

> what is the difference in protocol?
[Qiong] I list some of the differences below:
1) In lw4over6, IPv6 address does not have IPv4-related semantics, while in
MAP, IPv6 address has IPv4-related semantics (EA-bits)
2) In lw4over6, there is no need to import mapping rules, e.g. FMRs, etc.,
to CPEs, and there is no need for CPEs to understand the IPv6 prefix rule
length, IPv4 prefix rule length, etc.
3) In lw4over6, lwAFTR can support dynamically creating, deleting,
renewing, and maintaining these subscriber bindings. This will greatly
reduce the configuration overload and trouble shooting. While in MAP, the
BR and CE MUST be configured with the MAP elements (section 7 of
draft-ietf-softwire-map).

> are the bits on the wire between these two proposals different?
[Qiong] The two proposals not only define the "bits on the wire", but also
the functionalities need to be supported in both CE/lwB4 and BR/lwAFTR.

Best wishes
Qiong

Open source code:

---

From: Qiong <[email-masked]>
Date: Tue, 13 Nov 2012 11:57:07 +0800

+1 agree.

If there is no "mapping with addressing and port" at all, how can it still
be called MAP anymore ?

Best wishes
Qiong

Open source code:

---

From: Qi Sun <[email-masked]>
Date: Tue, 13 Nov 2012 12:56:28 +0800

If you need to advertise summary routes (as in MAP-E), IPv4 and IPv6 address are coupled, i.e. IPv4 info is embedded in IPv6 prefix. But for advertising host routes (as in Lw4over6), IPv4 and IPv6 address are decoupled, which is needed by many operators.

IPv4 and IPv6 coupled or decoupled, that is not a deployment choice.

BR,
Qi Sun

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 13 Nov 2012 15:06:38 +0900

Qiong,

On 2012/11/13, at 12:57, Qiong <[email-masked]> wrote:

> +1 agree.
> 
> If there is no "mapping with addressing and port" at all, how can it still be called MAP anymore ? 

It is conventional naming. Even DS-Lite has mapping with address and port. Please keep discussion constructively.
--satoru

---

From: Qi Sun <[email-masked]>
Date: Tue, 13 Nov 2012 15:50:35 +0800

> It is conventional naming. Even DS-Lite has mapping with address and port. Please keep discussion constructively.

[Qi] Would you specify which part in DS-Lite?

---

From: "Yuchi Chen" <[email-masked]>
Date: Tue, 13 Nov 2012 15:56:47 -0500

Hi Satoru,

I think the main issue here is not about "naming", but about the original motivation of MAP. AFAIK MAP draft promotes a stateless provisioning method using mapping with address and port. Although the algorithm MAP draft promotes is kind of complicated and couples v4 and v6 addresses, which introduces a potential threat of flexibility, but it's well designed and beautiful indeed and makes MAP attractive to those who want such a stateless solution. If MAP turns out a stateful solution in 1:1 mode (no matter what kind of state it's like), I don't think it will be so charming to these people any more, and I think people who wants 1:1 may prefer to another solution which is much simpler, satisfies the 1:1 scenario well and does not introduce any flexibility problem. 

It will be appreciated if you would so kind clarify the real motivation of MAP, and the meaning of 'mapping' you used to describe the DS-Lite (which is a well-known stateful solution) if possible, and thus it may help us keep discussion more constructively.

Best regards!

Yuchi Chen

From: Satoru Matsushima
Date: 2012-11-13 01:06
To: Qiong
CC: [email-masked]

---

From: Leaf yeh <[email-masked]>
Date: Tue, 13 Nov 2012 08:01:41 +0000

I guess '4over6' sounds a better name for the solution whether it has IPv6(A) mapping for IPv4(A+P) or not.

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Satoru Matsushima
Sent: Tuesday, November 13, 2012 2:07 PM
To: Qiong
Cc: [email-masked]
Subject: Re: [Softwires] MAP-E 1:1 for HA

Qiong,

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 13 Nov 2012 17:45:00 +0900

Hi Yuchi,

On 2012/11/14, at 5:56, "Yuchi Chen" <[email-masked]> wrote:

> Hi Satoru,
>  
> I think the main issue here is not about "naming", but about the original motivation of MAP. AFAIK MAP draft promotes a stateless provisioning method using mapping with address and port. Although the algorithm MAP draft promotes is kind of complicated and couples v4 and v6 addresses, which introduces a potential threat of flexibility,

MAP introduce complication and flixibility threat!? Not at all.
So then, could you answer how much complicated is complicated, and how much flexibility do you need?

> but it's well designed and beautiful indeed and makes MAP attractive to those who want such a stateless solution. If MAP turns out a stateful solution in 1:1 mode (no matter what kind of state it's like), I don't think it will be so charming to these people any more, and I think people who wants 1:1 may prefer to another solution which is much simpler, satisfies the 1:1 scenario well and does not introduce any flexibility problem.

Why 1:1 is stateful?
I'm not clear where is the threshold to distinguish stateful and stateless? N=2, 3, or 4???

> It will be appreciated if you would so kind clarify the real motivation of MAP, and the meaning of 'mapping' you used to describe the DS-Lite (which is a well-known stateful solution) if possible,…

Doesn't AFTR maintain mapping of remote IPv6 endpoint address with IPv4 address and port?

cheers,
--satoru

---

From: Qiong <[email-masked]>
Date: Tue, 13 Nov 2012 17:05:33 +0800

Exactly!  '4over6' indicates v4 address and v6 address is decoupled...

Best wishes
Qiong

Open source code:

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 13 Nov 2012 18:09:47 +0900

> I guess '4over6' sounds a better name for the solution whether it has IPv6(A) mapping for IPv4(A+P) or not.

Do you suggest DS-Lite should change its name to 4over6 too?
--satoru

---

From: Leaf yeh <[email-masked]>
Date: Tue, 13 Nov 2012 09:26:06 +0000

'4over6' could be DS-Lite 2.0, which may also embrace MAP-E;  '4via6' could be a better name for MAP-T in the same logic below. :-)

Best Regards,
Leaf

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 13 Nov 2012 18:31:40 +0900

> '4over6' could be DS-Lite 2.0, which may also embrace MAP-E;  '4via6' could be a better name for MAP-T in the same logic below. :-)

You may write a draft to propose it. ;)
--satoru

---

From: "Yuchi Chen" <[email-masked]>
Date: Tue, 13 Nov 2012 21:15:31 -0500

Hi Satoru,

Please see inline.

Best regards!
--------------
Yuchi Chen
>So then, could you answer how much complicated is complicated, and how much flexibility do you need?
[Yuchi] I don't think the discussion on definitions or degrees of 'complicated' and 'flexibility' is so constructive, and I don't think it will make any sense here.

>I'm not clear where is the threshold to distinguish stateful and stateless? N=2, 3, or 4???
[Yuchi] I believe that the differences between stateful and stateless are well discussed in the previous discussions. The point I want to figure out here is that MAP 1:1 mode is not so 'stateless' as other parts of MAP-E. 

>Doesn't AFTR maintain mapping of remote IPv6 endpoint address with IPv4 address and port?
[Yuchi] Actually there is a 'binding' table on the AFTR, which maintains matching between v4 A+P and v6 A, and there's no 'mapping with address and port' in DS-Lite or Lw4over6 as in MAP. The main point here is not about the literal difference between 'binding' and 'mapping', but the difference between decoupling v4 & v6 and coupling v4 & v6.

---

From: Ole Trøan <[email-masked]>
Date: Tue, 13 Nov 2012 14:46:03 +0100

> [Yuchi] Actually there is a 'binding' table on the AFTR, which maintains matching between v4 A+P and v6 A, and there's no 'mapping with address and port' in DS-Lite or Lw4over6 as in MAP. The main…

let us assume we have a 1.1.1.0/24 for address sharing available with 256 ports per user.

in MAP 1:1 you'd have:
  1.1.1.1:01/40 -> 2001:db8::1
  1.1.1.1:02/40 -> 2001:db8::2
  1.1.1.1:03/40 -> 2001:db8::3
  .
  .
  .

  64K rules.

in MAP aggregated mode you have:
  1.1.1.0/24 -> 2001:db8:XXXX::/48

can you please show how the LW46 rules / binding /mapping whatever you call them look like for 1:1 mode?

cheers,
Ole

---

From: "Yuchi Chen" <[email-masked]>
Date: Tue, 13 Nov 2012 23:29:35 +0800

Hi Ole,

I'm not so sure what you want to point out with the example. Of course I can show an example of binding table on the AFTR, but I wonder why and what can be achieved to do that here. The quote you made is just trying to figure out that the notion of 'mapping' in MAP is different from 'binding' in DS-Lite/Lw4over6 (it's not just a literal difference as I said).

Best regards!

Yuchi Chen

From: Ole Trøan
Date: 2012-11-13 21:46
To: chenycmx
CC: Satoru Matsushima; softwires WG
Subject: Re: [Softwires] MAP-E 1:1 for HA

in MAP 1:1 you'd have:

  64K rules.

cheers,
Ole

---

From: Ole Trøan <[email-masked]>
Date: Tue, 13 Nov 2012 19:35:42 +0100

Yuchi,

> I'm not so sure what you want to point out with the example. Of course I can show an example of binding table on the AFTR, but I wonder why and what can be achieved to do that here. The quote you m…

my point is that your LW46 mapping table will look exactly like the MAP 1:1 table. no?

cheers,
Ole

---

From: Mark Townsley <[email-masked]>
Date: Tue, 13 Nov 2012 22:02:48 +0100

On Nov 10, 2012, at 5:05 AM, Qiong wrote:

> [Qiong] Actually, that's not the same. If we only need /32, there is no need to do LPM implementation anymore, only exact matching is needed and this is much eaiser than LPM. LPM is not optimized for /32 routing lookup. 
> The reason that current routers still implement LPM rather not exact matching is because /32 is a truely corner case in RIB. However, if /32 is not a corner case, but is the major requirement for operators, I believe more efficient way should be introduced.

The PPP protocol is the same whether it is used on a router to router serial link or a BNG terminating 100,000s of PPPoE and L2TP sessions.  DHCP is still DHCP whether being used to provision millions of routers in a broadband network, a few in your home, on a wireless or wired enterprise network, etc. etc... Of course implementations are optimized and scaled differently, and may even have different tweaks or options depending on how it is being used, but the protocol itself is the same whether it is used in one type of deployment or another. Should we have had separate RFCs and marketing names for every environment PPP and DHCP have been used in? 

- Mark

> PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/

---

From: "Yuchi Chen" <[email-masked]>
Date: Wed, 14 Nov 2012 15:22:14 +0800

Hi Ole,

From my perspective, your MAP 1:1 mapping table looks not so really like Lw4over6 binding table, which can be established in a static or dynamic way or both.

AFAIK all the 1:1 rules in your mapping table must be pre-configured statically as other rules in MAP aggregated mode, which means that with the 1.1.1.0/24 for address sharing available with 256 ports per user, the BR can just support exactly 64K CEs at most. However, as the lwAFTR allocates IPv4 addresses and ports dynamically, with these resources the lwAFTR can keep 64K lwB4s connected simultaneously, and nobody knows how large the number of lwB4s that the lwAFTR can support at most can be. Please note that this number could be much larger than 64K, because not all the supported lwB4s may be online at the same time. IMHO that the MAP mapping table can just be configured statically seems to be a limit when it comes to 1:1 scenario.

Best regards!

Yuchi Chen

From: Ole Trøan
Date: 2012-11-14 02:35
To: chenycmx
CC: Satoru Matsushima; softwires WG
Subject: Re: [SUSPECTED SPAM] Re: Re: [Softwires] MAP-E 1:1 for HA
Yuchi,

cheers,
Ole

---

From: Qi Sun <[email-masked]>
Date: Thu, 15 Nov 2012 00:03:03 +0800

Ole,

>  1.1.1.0/24 -> 2001:db8:XXXX::/48

Actually, the so called 'aggregated mode' is original MAP-E, with IPv4 address and PSID embedded in the EA-bits field in End user IPv6 prefix. Let me try to explain what you have 'aggregated'.

1.1.1.1:01 -> 2001:db8:101::/48 (EA-bits: 0x101)
1.1.1.1:02 -> 2001:db8:102::/48 (EA-bits: 0x102)
1.1.1.1:03 -> 2001:db8:103::/48 (EA-bits: 0x103)
.
.
.

The IPv4 address and port set are the same in what you called 'MAP 1:1'. However, the corresponding IPv6 addresses are totally different. Because one uses MAP algorithm, the other doesn't. 

The original MAP-E achieves address sharing by embedding IPv4 suffix and PSID into End User IPv6 prefix. But if the EA-bits is ZERO, PSID is also ZERO. Nothing embedded in the IPv6 prefix. In this case, the so called 'MAP 1:1' abandons the MAP algorithm and uses a per-subscriber stateful kind method to achieve address sharing. That is NOT MAP-E. 

So I question why 'MAP-E 1:1' bears the MAP-E name.

Qi Sun

---

From: Ole Trøan <[email-masked]>
Date: Wed, 14 Nov 2012 17:59:05 +0100

> So I question why 'MAP-E 1:1' bears the MAP-E name.

I really don't care what we call it. what we are talking about is simply RFC2473 tunneling with extensions from RFC6346.
if you want to, please suggest whatever name you like.

what I'm arguing against is that we need a separate RFC for the mechanism if it uses a /48 versus if it uses a /40.

cheers,
Ole

---

From: Shin Miyakawa <[email-masked]>
Date: Thu, 15 Nov 2012 08:08:06 +0900 (JST)

Ole,

By the way... I think, you should NOT use 1.1.1.1 as example.

1/8 is not a document prefix nor private address space
but global space which belongs to APNIC.

Cheers,

Shin Miyakawa

From: Ole Trøan <[email-masked]>
Subject: Re: [Softwires] MAP-E 1:1 for HA
Date: Tue, 13 Nov 2012 14:46:03 +0100

---

From: Qiong <[email-masked]>
Date: Thu, 15 Nov 2012 10:44:51 +0800

Ole,

On Thu, Nov 15, 2012 at 12:59 AM, Ole Trøan <[email-masked]> wrote:

> > Actually, the so called 'aggregated mode' is original MAP-E, with IPv4
> address and PSID embedded in the EA-bits field in End user IPv6 prefix. Let
> me try to explain what you have 'aggregated'.
> >
> > The IPv4 address and port set are the same in what you called 'MAP 1:1'.
> However, the corresponding IPv6 addresses are totally different. Because
> one uses MAP algorithm, the other doesn't.
> >
> >
> > The original MAP-E achieves address sharing by embedding IPv4 suffix and
> PSID into End User IPv6 prefix. But if the EA-bits is ZERO, PSID is also
> ZERO. Nothing embedded in the IPv6 prefix. In this case, the so called 'MAP
> 1:1' abandons the MAP algorithm and uses a per-subscriber stateful kind
> method to achieve address sharing. That is NOT MAP-E.
> >
> I really don't care what we call it. what we are talking about is simply
> RFC2473 tunneling with extensions from RFC6346.
> what I'm arguing against is that we need a separate RFC for the mechanism
> if it uses a /48 versus if it uses a /40.
>

[Qiong] The reason here is that they are actually two mechanisms steps from
different motivations and requirements. That's why they will result in two
kinds of rules/binding/or ...with the same 'aggregated' IPv4 rule.

Best wishes
Qiong

Open source code:

---

From: Ole Trøan <[email-masked]>
Date: Thu, 15 Nov 2012 09:23:18 +0100

Shin,

> but global space which belongs to APNIC.

too right.
s/1.1.1.1/192.0.2.1/g

apologies for spreading the usage of 1/8.

cheers,
Ole

---

From: Qi Sun <[email-masked]>
Date: Thu, 15 Nov 2012 13:40:42 +0800

Ole,

Qi Sun

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 15 Nov 2012 23:19:27 +0000

Hi Rajiv,

With all due respect, I disagree the analogy. Comparing MAP-E to routing
protocol is comparing apple to orange. MAP-E is not a routing protocol.
MAP-E won't synchronize or exchange states between two BRs. Instead, MAP-E
requires to statically provision states (aka rules) in the BR. Original
MAP-E describes a mechanism to reduce user states in BR by using
programatic logic. 1:1 MAP-E does not require any of the good stuff
defined in MAP-E. I just found it odd to combine stateful and stateless
mechanisms in a single draft and use a same name.

Thanks,
Yiu

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 26 Nov 2012 09:25:10 +0100

Yiu,

What's your definition of "state" (as in stateful)?

-Woj.

On 16 November 2012 00:19, Lee, Yiu <[email-masked]> wrote:

> >To: Rajiv Asati <[email-masked]>, Softwires-wg list <[email-masked]
> >

---

From: Mark Townsley <[email-masked]>
Date: Thu, 29 Nov 2012 15:03:40 +0100

I think Rajiv's point is more about how summarization of routes in IP brings fundamental scalability advantages for IP routers, not whether the routes are programmed with a what is traditionally referred to as a "routing protocol" or via CLI, DHCP, netconf/yang, XML, or however the MAP rules are programmed in a given network.

Another way of saying this is that, in IP (v4, for example here) a /32 route is no different than a /31, /24, etc. other than a /32 just happens to refer to one address rather than two or more. The routing system *could* be run with /32s everywhere, and while scalability would suffer tremendously, hosts would have the flexibility to be numbered with a static unique address no matter where the user connected to the network. The system would have IP mobility built right in! No need for Mobile IP tunnels!  It's all possible right now, just turn the state dial all the way to the right and enjoy. The point where your existing equipment falls over requiring you to redesign the network accordingly depends on the number of hosts, limitations in routers, churn and convergence, etc. but there is nothing prohibiting this per se in the protocol design - it's all just IP and CIDR.

Relating this to MAP: At one extreme, you can choose to setup rules in advance such that rule aggregation is possible to a degree whereby MAP can be supported inline with routers positioned where they normally would for regular IPv6 forwarding. At the other extreme, you have less aggregation and at some point you'll probably have to introduce special-purpose tunnel concentrator hardware at specific locations. The point where this crossover occurs isn't necessarily at the 1:1 MAP rule point, it could be 2:1, 8:1, 256:1... it all depends on how many MAP rules are supported by the vendor equipment chosen and the number of endpoints being addressed.

Just as map supports 2^32:1,... 8192:1, 4096:1, 2048:1, 512:1, 256:1, 128:1, 64:1, 32:1, 16:1, 8:1, 4:1, or 2:1, it follows pretty clearly that it should also support 1:1 - to do otherwise would be arbitrary. I think the only question that should be on the table is whether a 1:1 rule is called something different or not - kind of like how we refer to a /32 or /128 as a hostroute. We could have a MAP "hostrule" for 1:1, and "aggregate-rule" for N:1. Vendor equipment optimized for 1:1 mode would advertise how many "hostrules" it can support. A more general MAP implementation might advertise x number of "rules", aggregate or not. The protocol mechanism from Softwires remains happily agnostic to all of this; To the protocol, its nothing more than semantics.

Bottom line, "Stateless operation" is a variable tipping point... It's roughly the point where you can no longer affordably stuff all rules into all border routers in your network. If you have 2 rules for millions of endpoints, it's pretty easy to see that stateless operation is possible. If you have millions of rules for millions of endpoints, it's probably not. It's all highly dependent on the hardware, size, and design of the network.

Softwires should focus on the best protocol design, and let the vendors, operators and market battle over where to turn the dial and what to optimize for in their implementations and deployments.

- Mark

---

From: Leaf yeh <[email-masked]>
Date: Fri, 30 Nov 2012 04:13:30 +0000

Mark - I think the only question that should be on the table is whether a 1:1 rule is called something different or not - kind of like how we refer to a /32 or /128 as a hostroute.

Even in the case of MAP-E 1:1, there still has 2 kinds of deployments:

a.  map PSID into the EA bits of the delegated end-user IPv6 prefix;
b.  length of EA bits = 0, which might mean no mapping at all;

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Townsley
Sent: Thursday, November 29, 2012 10:04 PM
To: Lee, Yiu
Cc: [email-masked]
Subject: Re: [Softwires] MAP-E 1:1 for HA

- Mark

---

From: Qiong <[email-masked]>
Date: Fri, 30 Nov 2012 16:48:26 +0800

Right. That's why I prefer the solution space provided by Med before, which
will be much clearer and easy to understand:
* Full stateful approach
* Binding approach
* Full stateless approach

Best wishes
Qiong

On Fri, Nov 30, 2012 at 12:13 PM, Leaf yeh <[email-masked]> wrote:

> Mark - I think the only question that should be on the table is whether a
> 1:1 rule is called something different or not - kind of like how we refer
> to a /32 or /128 as a hostroute.

Open source code:

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 30 Nov 2012 11:51:27 +0100

And much as was also said before, this categorization is bogus as all
solutions need configuration state, ie categorizing solutions based on
"amount of configuration" or some fluffy term like "binding approach" is
equivalent to categorizing them based on "how long is a piece of string"
and ultimately useless. What we do know is one-size of string does not work
for all, and the implementers need to scale their configuration state as
per their best judgement/capabilities.

Cheers,
Woj.

On 30 November 2012 09:48, Qiong <[email-masked]> wrote:

> Right. That's why I prefer the solution space provided by Med before,
> which will be much clearer and easy to understand:
> * Full stateful approach
> * Binding approach

---

From: Qi Sun <[email-masked]>
Date: Fri, 30 Nov 2012 20:37:09 +0800

This solution space is the outcome of Vancouver meeting. And IMO, the word 'binding' not only means there are state to maintain, but also indicates that IPv4 and IPv6 addresses are just bound together, with no algorithmic relationship.

Thanks,

Qi Sun

On 2012-11-30, at 下午6:51, Wojciech Dec wrote:

> And much as was also said before, this categorization is bogus as all solutions need configuration state, ie categorizing solutions based on "amount of configuration" or some fluffy term like "binding approach" is equivalent to categorizing them based on "how long is a piece of string" and ultimately useless. What we do know is one-size of string does not work for all, and the implementers need to scale their configuration state as per their best judgement/capabilities.
> 
> Cheers,
> Woj.
> 
> Right. That's why I prefer the solution space provided by Med before, which will be much clearer and easy to understand:
> * Full stateful approach
> * Binding approach

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 30 Nov 2012 16:40:34 +0100

On 30 November 2012 13:37, Qi Sun <[email-masked]> wrote:

> This solution space is the outcome of Vancouver meeting. And IMO, the word
> 'binding' not only means there are state to maintain, but also indicates
> that IPv4 and IPv6 addresses are just bound together, with no algorithmic
> relationship.
>

You just described an algorithm.

I will assert that the *only* tangible difference between is whether it is
derived from the data plane or not. Both lw46 and MAP do not derive their
state from the data plane, but from a higher control plane as opposed to
DS-lite/NAT44. Thus once again, coming up with "binding" categorization
appears to be a pointless exercise.
And yes, one must be able to maintain configuration state...

Thanks,
Woj.

>>> Mark - I think the only question that should be on the table is whether
>>> a 1:1 rule is called something different or not - kind of like how we refer

---

From: Ole Trøan <[email-masked]>
Date: Fri, 30 Nov 2012 19:34:02 +0100

All,

> * Full stateless approach

but why would a CPE have to know what amount of state a tunnel concentrator keeps?

cheers,
Ole