Subject: Re: [Softwires] map-00: review on the mode 1:1

From: Qiong <[email-masked]>
Date: Sat, 21 Jul 2012 17:46:45 +0800

Hi, Woj,

This is not only about determining which parameter to explicitly exist in MAP rule, but also the configuration in BR. If you include PSID explicitly, then
1) you need to configure per-subscriber rule in BR since the value of PSID for different CPEs are different. This will take a lot of workload for operators and it is obviously not the objective of any stateless solution.
2) IPv6 prefix has already carry the PSID implicitly, and the PSID in MAP rule is redundant.
Therefore, I don't see the reason to include PSID explicitly in MAP architecture.

Best wishes
Qiong

Wojciech Dec <[email-masked]>编写：

>Remi,
>
>On 20 July 2012 17:03, Rémi Després <[email-masked]> wrote:
>
>> Hi, Wojciech,
>>
>> 2012-07-20 12:56, Wojciech Dec:
>>
>> If the use of PSIDs in rules is useful, as it appears to be,
>>
>>
>> This is the point that needs to be explained.
>>
>
>The case is straightforward A+P.
>For a single IPv4 address + port range it is desired to have it correspond
>to an IPv6 address.
>MAP and 4rd-u have that as a well established case with the IPv4 address
>and / or PSID being mapped into the IPv6 prefix, but the IPv4 address not
>given that it is configured on both sides (implicit). There is nothing in
>the MAP architecture which restricts the PSID to not be such an implicit
>parameter given that it can be configured at either side.
>
>-Woj.
>
>
>
>> Thanks.
>> RD
>>
>>
>> then there seems to be no reason not to allow that.
>>
>> Regards,
>> Woj.
>>
>>
>>>
>>> - maoke
>>>
>>>
>>>>
>>>> Regards,
>>>> Woj.
>>>>
>>>>>
>>>>>
>>>>>
>> _______________________________________________
>> Softwires mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/softwires
>>
>>
>>
>
>_______________________________________________
>Softwires mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/softwires

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 23 Jul 2012 10:06:40 +0200

Qiong,

On 21 July 2012 11:46, Qiong <[email-masked]> wrote:

> Hi, Woj,
>
> This is not only about determining which parameter to explicitly exist in
> MAP rule, but also the configuration in BR. If you include PSID explicitly,
> then
> 1) you need to configure per-subscriber rule in BR since the value of PSID
> for different CPEs are different. This will take a lot of workload for
> operators and it is obviously not the objective of any stateless solution.
>

Stateless does not mean configuration less, and never did.
Even without an explicit PSID one could have thousands of "rules"
configured, if one chooses to deploy it that way.

> Therefore, I don't see the reason to include PSID explicitly in MAP

So you don't disagree about the use, which is good. I'm however puzzled by
why you see a need for a separate architecture document & specification to
address the need for explicit port range, which the explicit PSID is,
rather than working on a common solution...

Regards,
Woj.

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 25 Jul 2012 15:09:28 +0000

Woj,

I got a general question. The current MAP support 1:1 mode where EA-bit is a
full 32-bit address. Why we want to reinvent a wheel to create another 1:1
mode? The only difference is to move the configuration from DHCP server to
rules in the BR. Did I miss something?

Thanks,
Yiu

From:  Wojciech Dec <[email-masked]>
Date:  Monday, July 23, 2012 4:06 AM
To:  Qiong <[email-masked]>
Cc:  Softwires-wg <[email-masked]>
Subject:  Re: [Softwires] map-00: review on the mode 1:1

Qiong,

On 21 July 2012 11:46, Qiong <[email-masked]> wrote:
> Hi, Woj,
> 
> This is not only about determining which parameter to explicitly exist in MAP
> rule, but also the configuration in BR. If you include PSID explicitly, then
> 1) you need to configure per-subscriber rule in BR since the value of PSID for
> different CPEs are different. This will take a lot of workload for operators
> and it is obviously not the objective of any stateless solution.

So you don't disagree about the use, which is good. I'm however puzzled by
why you see a need for a separate architecture document & specification to
address the need for explicit port range, which the explicit PSID is, rather
than working on a common solution...

Regards,
Woj.
 
> For a single IPv4 address + port range it is desired to have it correspond to
> an IPv6 address.
> MAP and 4rd-u have that as a well established case with the IPv4 address and /
> or PSID being mapped into the IPv6 prefix, but the IPv4 address not given that
> it is configured on both sides (implicit). There is nothing in the MAP
> architecture which restricts the PSID to not be such an implicit parameter
> given that it can be configured at either side.
> 
> -Woj.
> 
>  
>> Thanks.
>> RD
>>

---

From: Ole Trøan <[email-masked]>
Date: Wed, 25 Jul 2012 19:04:27 +0200

Yiu,

> I got a general question. The current MAP support 1:1 mode where EA-bit is a full 32-bit address. Why we want to reinvent a wheel to create another 1:1 mode? The only difference is to move the configuration from DHCP server to rules in the BR. Did I miss something?

just the opposite. MAP supports 1:1 mode with no EA bits. all the bits are encoded in the MAP DHCP option.
this is just a logical implications of the fields already in that option.

cheers,
Ole

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 25 Jul 2012 18:12:41 +0000

Ole,

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?

Thanks,
Yiu

Why we want to 

On 7/25/12 1:04 PM, "Ole Trøan" <[email-masked]> wrote:

>Yiu,
>
>> I got a general question. The current MAP support 1:1 mode where EA-bit
>>is a full 32-bit address. Why we want to reinvent a wheel to create
>>another 1:1 mode? The only difference is to move the configuration from
>>DHCP server to rules in the BR. Did I miss something?
>

---

From: Ole Trøan <[email-masked]>
Date: Wed, 25 Jul 2012 20:40:54 +0200

Yiu,

> 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

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 25 Jul 2012 19:08:04 +0000

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.

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

Questions to WG:
Is it useful feature to be included in MAP? If not, why and alternative?

Thanks,
Yiu

---

From: Satoru Matsushima <[email-masked]>
Date: Thu, 26 Jul 2012 10:45:29 +0900

Hi Yiu,

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

> 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

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.

> 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

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 26 Jul 2012 01:51:47 +0000

Hi Satoru,

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.

Thanks,
Yiu

On 7/25/12 9:45 PM, "Satoru Matsushima" <[email-masked]>
wrote:

>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.
>
>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:
>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
>> 
>>>> I am not asking whether MAP supports 1:1 mode with no EA bits or not.
>>>>I
>>>> am
>>> 1:1 mode is typically referred to a model where IPv4 and IPv6
>>>addressing
>>> are independent.
>>> 
>>> cheers,
>>> Ole
>>>

---

From: Ole Trøan <[email-masked]>
Date: Thu, 26 Jul 2012 12:22:45 +0200

Yiu,

> 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

---

From: Peng Wu <[email-masked]>
Date: Thu, 26 Jul 2012 19:17:22 +0800

Ole,

As I suggested earlier, you could simply say that the WHOLE
ARCHITECTURE is based on IPv4-IPv6 address embedding and because
setting EA bits=0 changes this very basic assumption, it's not
allowed/supported in MAP.

IMHO it's the best way to keep MAP clean and clear. And I don't think
it'll cause problems: you want statelessness, you couple v4-v6
addressing and use MAP; you want v4-v6 addressing independency rather
than statelessness, then that's another story.

---

From: <[email-masked]>
Date: Thu, 26 Jul 2012 14:06:00 +0200

Dear Ole, all,

For sure MAP spec can be updated to cover 1:1 mode but this brings more confusion for some people as this contradicts the "no state in ISP network" paradigm. I personally vote for limiting MAP to its initial scope rather than trying to cover other deployment options.

I see three main flavours which justifies having standalone specification documents:

(1) Full stateful mode: DS-Lite
(2) Full stateless mode: MAP/4rd
(3) Per-customer state/binding mode: lw4o6 (draft-cui-softwire-b4-translated-ds-lite)

These three flavours have been already sketched in Figure 7 of RFC6346 (see http://tools.ietf.org/html/rfc6346#section-3.3.4).

Having standalone specifications for each of these flavours helps operators to better target their suitable deployment model without being disturbed with parameters and details not pertinent for their deployment context.

Cheers,
Med 

>-----Message d'origine-----
>De : [email-masked] 
>[mailto:[email-masked]] De la part de Ole Trøan
>Envoyé : jeudi 26 juillet 2012 12:23
>À : Lee, Yiu
>Cc : Softwires-wg
>Objet : Re: [Softwires] map-00: review on the mode 1:1
>
>Yiu,
>
>>>> Where can I get the formal definition of 1:1 mode? My 
>understanding of
>>>> 1:1
>>>>> embedding a complete IPv4 address and PSID does require a 
>lot of IPv6
>>>>> space though.
>>>>> e.g. /56 - 32 - 6 = /18
>>>>>

---

From: Rémi Després <[email-masked]>
Date: Thu, 26 Jul 2012 14:09:59 +0200

> (3) Per-customer state/binding mode: lw4o6 (draft-cui-softwire-b4-translated-ds-lite)

Same view.
RD

---

From: Maoke <[email-masked]>
Date: Thu, 26 Jul 2012 23:34:11 +0900

2012/7/26 <[email-masked]>

> Dear Ole, all,
>
> For sure MAP spec can be updated to cover 1:1 mode but this brings more
> confusion for some people as this contradicts the "no state in ISP network"
> paradigm. I personally vote for limiting MAP to its initial scope rather
> than trying to cover other deployment options.
>
> (3) Per-customer state/binding mode: lw4o6
> (draft-cui-softwire-b4-translated-ds-lite)
>
> These three flavours have been already sketched in Figure 7 of RFC6346
> (see http://tools.ietf.org/html/rfc6346#section-3.3.4).
>
>
yes. i share this point. thanks, Med, for the clear explanation on the big
picture. - maoke

> Having standalone specifications for each of these flavours helps
> operators to better target their suitable deployment model without being
> disturbed with parameters and details not pertinent for their deployment
> context.
>
> Cheers,
> Med
>

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 26 Jul 2012 14:59:00 +0000

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.

Thanks,
Yiu

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 27 Jul 2012 13:59:51 +0200

Med,

 2) and 3) both require configuration and as has been amply discussed
technically there is no issue with per subscriber rules in 2) or
optimization applying to 3). As such, justifying three different solutions
out of which two can technically have the same amount of configuration
state and are almost the same appears illogical.
>From another perspective, defining a solution that by definition requires
per subscriber configuration state and does not allow its optimization is
highly questionable technically.

Regards,
Woj.

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 27 Jul 2012 14:06:08 +0200

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

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 27 Jul 2012 12:39:30 +0000

Woj,

I am confused. You said "given that EA=0 is already covered (eg embedding of
full IPv4 address, no address sharing, if not the other case)". If I read
the spec right, this is my understanding: If I want to embed full v4 address
in the CE v6 address, the v4 address will be embedded in the EA. If so, how
would EA=0? 

"The EA bits encode the CE specific IPv4
   address and port information.  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)."

I prefer one solution vs. N solutions given that the one solution can
logically solve all problems and doesn't cause confusion. Consider we agreed
on including 1:1 MAP. When an operator deployed it, he had to ask if I want
to share v4 addresses, should I put the v4 info in the EA or set EA=0 and
provision PSID? It will create unnecessary confusion. Simply put I am not
"calling out for a "remove that part of the spec & complicate it" case". My
position is quite an opposite. I am calling out for "not adding confusion to
complicate a spec".

In the end, it is up to WG to decide.

Thanks,
Yiu

From:  Wojciech Dec <[email-masked]>
Date:  Friday, July 27, 2012 8:06 AM
To:  "Yiu L. LEE" <[email-masked]>
Cc:  Ole Trøan <[email-masked]>, Softwires-wg <[email-masked]>
Subject:  Re: [Softwires] map-00: review on the mode 1:1

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.
>>>>> >>>> Where can I get the formal definition of 1:1 mode? My understanding
of
>>>>>> >>>>> embedding a complete IPv4 address and PSID does require a lot of
IPv6

---

From: <[email-masked]>
Date: Fri, 27 Jul 2012 14:40:03 +0200

Woj,

The argument you are raising applies also for (1) and (3): one can argue this justifies editing an RFC6333-bis to cover the per-subscriber state case ;-)

As I mentioned in my first message, MAP can be extended to cover the per-subscriber case at the cost of adding confusion by abandoning the "no state in the ISP network paradigm" not to mention the incompatibility with the translation mode (part of the MAP suite), etc.

IMO, the issue is not technical. It is more a matter of rationalizing the solution space. Having the three deployment options listed below is IMHO a good direction to take by the WG.

Cheers,
Med

________________________________
De : Wojciech Dec [mailto:[email-masked]]
Envoyé : vendredi 27 juillet 2012 14:00
À : Maoke
Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; Softwires-wg
Objet : Re: [Softwires] map-00: review on the mode 1:1

Med,

 2) and 3) both require configuration and as has been amply discussed technically there is no issue with per subscriber rules in 2) or optimization applying to 3). As such, justifying three different solutions out of which two can technically have the same amount of configuration state and are almost the same appears illogical.
>From another perspective, defining a solution that by definition requires per subscriber configuration state and does not allow its optimization is highly questionable technically.

Regards,
Woj.

On 26 July 2012 16:34, Maoke <[email-masked]<mailto:[email-masked]>> wrote:

2012/7/26 <[email-masked]<mailto:[email-masked]>>

Dear Ole, all,

yes. i share this point. thanks, Med, for the clear explanation on the big picture. - maoke

Cheers,
Med

>De : [email-masked]<mailto:[email-masked]>
>[mailto:[email-masked]<mailto:[email-masked]>] De la part de Ole Trøan
>> On 7/25/12 9:45 PM, "Satoru Matsushima" <[email-masked]<mailto:[email-masked]>>
>> wrote:
>>
>>> Hi Yiu,
>>>
>>>> On 7/25/12 2:40 PM, "Ole Trøan" <[email-masked]<mailto:[email-masked]>> wrote:
>>>>
>>>>> Yiu,
>>>>>
>>>> [email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>
_______________________________________________
Softwires mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/softwires

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

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 27 Jul 2012 15:03:18 +0200

Ole's and Satoru's eaerlier replies on this thread described the "how", and
even Maoke's earlier post on this thread acknowledged EA=0 with full IPv4
to be a " naturally established case of the MAP". EA=0 simply means that
there isn't IPv4 (or PSID)  info in the IPv6 prefix.

In terms of your question: When the EA=0, the full v4 address is derived
via DHCP (or other) configuration. If the operator wants to configure
address sharing, then a PSID is also required to be configured. This is
saying , " you have to have an IPv4 address, and besides that if you want
address sharing, you have to configure a port range via a PSID", which is
unlikely to be confusing to any operator who is interested in doing any of
this.

That said, even if it the draft can better articulate this use, (which
draft-00 actually sought to do), that not being so is hardly grounds for
having yet another solution and draft to deal with this use-case. In terms
of causing operator confusion, that by far is more confusing.

Thanks,
Woj.

On 27 July 2012 14:39, Lee, Yiu <[email-masked]> wrote:

> Woj,
>
> I am confused. You said "given that EA=0 is already covered (eg embedding
> of full IPv4 address, no address sharing, if not the other case)". If I
> read the spec right, this is my understanding: If I want to embed full v4
> address in the CE v6 address, the v4 address will be embedded in the EA. If
> so, how would EA=0?
>
> logically solve all problems and doesn't cause confusion. Consider we
> agreed on including 1:1 MAP. When an operator deployed it, he had to ask if
> I want to share v4 addresses, should I put the v4 info in the EA or set
> EA=0 and provision PSID? It will create unnecessary confusion. Simply put I
> am not "calling out for a "remove that part of the spec & complicate it"
> case". My position is quite an opposite. I am calling out for "not adding
> confusion to complicate a spec".
>

---

From: Qiong <[email-masked]>
Date: Fri, 27 Jul 2012 21:28:46 +0800

Woj,

According to your description, it is clear that the way to deal with EA=0
is quite different with EA>0. Mixing them together will not only make MAP
losing the initial "no state in the ISP network paradigm" spirit, but also
make MAP a lot more complex and confusing.

Actually, the use case for EA=0 and EA>0 stems from different requirements,
it is nature to treat them with seperately.

Best wishes
Qiong

On Fri, Jul 27, 2012 at 9:03 PM, Wojciech Dec <[email-masked]> wrote:

> Ole's and Satoru's eaerlier replies on this thread described the "how",
> and even Maoke's earlier post on this thread acknowledged EA=0 with full
> IPv4 to be a " naturally established case of the MAP". EA=0 simply means
> that there isn't IPv4 (or PSID)  info in the IPv6 prefix.
>
>> 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

-- 
==============================================
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: Peng Wu <[email-masked]>
Date: Fri, 27 Jul 2012 21:43:40 +0800

On Fri, Jul 27, 2012 at 9:28 PM, Qiong <[email-masked]> wrote:
> Woj,
>
> According to your description, it is clear that the way to deal with EA=0 is
> quite different with EA>0. Mixing them together will not only make MAP
And for the case of EA bits=0, 90% of the MAP specification is not needed.
(v4 addr, PSID) provisioning, BR v6 addr provisioning and (v4 addr,
PSID, v6 addr) binding on BR, that's all. No one needs to learn any
thing about "mapping rules" what so ever.

>>> of full IPv4 address, no address sharing, if not the other case)". If I read
>>>> >> v4 address in the EA-bit. However, the operation models of EA-bit>0
>>>> >> or
>>>> >>=0
>>>> >what do you say in the spec if EA=0 and provisioned IPv4 prefix length
>>>> > =
>>>> >32.
>>>> >>> I believe that it does not make sense to restrict EA-len > 0 for
>>>> >>> both
>>>> >>>MAP
> lightweight 4over6: http://sourceforge.net/projects/laft6/
> PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Fri, 27 Jul 2012 15:48:35 +0200

On 7/27/12 2:39 PM, Lee, Yiu wrote:
> agreed on including 1:1 MAP. When an operator deployed it, he had to ask
> if I want to share v4 addresses, should I put the v4 info in the EA or
> set EA=0 and provision PSID? It will create unnecessary confusion.
> Simply put I am not "calling out for a "remove that part of the spec &
> complicate it" case". My position is quite an opposite. I am calling out
> for "not adding confusion to complicate a spec".

Hi,

I'm just admiring how the WG (usual suspects) manages to talk about the 
intention to simplify things and at the end everything ends up three 
times more complex than at the beginning.

In the RFC6346 we specified the architecture and the idea of A+P way of 
sharing resources. The idea was simple, clean and understandable.

Now even I don't understand completely A+P anymore and that's probably a 
bad sign - and adding also a 4RD flavor with all the header hacks did 
not help either.

So, on 1:1 - Idea of having 1:1 is simply to be able to do gradual 
deployment of A+P. In ideal world, ISP today would be able to buy from 
his favorite vendor A+P solution, started sending out new CPEs that are 
A+P capable/aware and connect them to PRR with full IP address assigned 
- so no change for a user as for now. Operator would be also able to 
change the CPE-base with sending new CPEs to old customers when they break.

When operator starts getting short on IPv4 supplies, he simply 
introduces address sharing and changes the customers communication 
behaviour with a flick of the switch on services configuration page - or 
even better, customer applies for sharing because less price of the deal 
or something similar. In this case CPE gets port-restricted address next 
time it reconnects.

So, from operational point of view, it is very important that the switch 
from 1:1 to sharing model is smooth, easy and a matter of one checkbox 
in services webpage - and it should be done on per-customer granularity.

That's it. Very simple. That was how the idea should work in ideal world.

But we are not there. A+P was delayed for years because of some people 
here - but finally even those people understood that this is the only 
alternative to CGN rubbish, that is currently taking over the Internet 
infrastructure.

Please stop complicating things and fighting whose flavor is better or 
who's ***** is longer and loosing time.

We need solid standard asap and I really don't care whose name is on the 
top of the RFC(s).

Med correctly pointed to the skech in RFC6346 and I hope just options 1 
and 2 will be used in real world.

Cheers, Jan

P.S: Unfortunately I cannot make it to Vancouver, but I encourage you 
all to go into that room, lock the door and don't leave it without a 
result and a clear idea, how to move forward quickly.

---

From: Qiong <[email-masked]>
Date: Fri, 27 Jul 2012 22:11:49 +0800

Hi Jan,

Thanks to bring this point out.  (sorry to re-send it to the wg)

What you described is exactly in draft-cui-softwire-b4-
translated-ds-lite, a per-subscriber level solution which solved the
requirements on:
1) NAT offloading from CGN to CPE
2) Flexibility on IPv6 address planning
3) IPv4/IPv6 decoupling
4) reduced logging
5) hub&spoke
6) support address sharing
7) very very very simple, clean and understandable

Of course, it does not solve the mesh scenario.

Best wishes

On Fri, Jul 27, 2012 at 9:48 PM, Jan Zorz @ go6.si <[email-masked]> wrote:

> intention to simplify things and at the end everything ends up three times
> more complex than at the beginning.
>
> bad sign - and adding also a 4RD flavor with all the header hacks did not
> help either.
>
> deployment of A+P. In ideal world, ISP today would be able to buy from his
> favorite vendor A+P solution, started sending out new CPEs that are A+P
> capable/aware and connect them to PRR with full IP address assigned - so no
> change for a user as for now. Operator would be also able to change the
> CPE-base with sending new CPEs to old customers when they break.
>
> When operator starts getting short on IPv4 supplies, he simply introduces
> address sharing and changes the customers communication behaviour with a
> flick of the switch on services configuration page - or even better,
> customer applies for sharing because less price of the deal or something
> similar. In this case CPE gets port-restricted address next time it
> reconnects.
>
> from 1:1 to sharing model is smooth, easy and a matter of one checkbox in
> services webpage - and it should be done on per-customer granularity.
>
> P.S: Unfortunately I cannot make it to Vancouver, but I encourage you all
> to go into that room, lock the door and don't leave it without a result and
> a clear idea, how to move forward quickly.
>
> ______________________________**_________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/softwires<https://www.ietf.org/mailman/listinfo/softwires>
>

Open source code: