Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG

From: <[email-masked]>
Date: Tue, 26 Jun 2012 09:13:00 +0200

Hi Satoru,

Comment in line below.

Best regards,
Ian

Date: Mon, 25 Jun 2012 18:46:18 +0900
From: Satoru Matsushima <[email-masked]<mailto:[email-masked]>>
To: Peng Wu <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>, Yong Cui <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does
NOTreflect the consensus from the WG
Message-ID: <[email-masked]<mailto:[email-masked]>>
Content-Type: text/plain; charset=iso-8859-1

Hi Peng,

On 2012/06/25, at 18:34, Peng Wu wrote:

Let's think that a CE provisioned with following BMR comes from MAP DHCPv6 options.
BMR:
  o Rule-ipv6-prefix  : {exact matched with CE's delegated prefix}
  o Rule-ipv4-prefix  : x.x.x.x/32
  o EA-length         : 0
  o Port-param option : {PSID/length}
This BMR could be a LW46 provisioning means.
Again, all the information needed is the IPv4 address and port set.
1) The item like rule-ipv6-prefix is not needed at all.
2) Port set or PSID still needs extra provisioning (while in regular
MAP it's embedded in IPv6 address)
So why make it so difficult and obscure

Not difficult, easy business for CE which implemented MAP. Other difficulty in operator side in particular provisioning complex, that should be same with LW46. It also makes to complete MAP spec in the ea-len zero case.

[IF] Additional complexity in the operator side is where I see the problem with MAP in our case. The strength that MAP offers is for the mesh model and the complexity that it brings is a neat way of achieving this. But if hub-and-spoke is the only deployment scenario that you need, then the complexity for mesh is an unnecessary addition that results in operational complexity, which is something we're trying to engineer out wherever we can.
E.g. In the case above, for a shared IP address, the source port range is encoded in the port-param option. To troubleshoot user connectivity, ops need to have a good understanding of how this is being calculated so that they can trace the user. Not the end of the world, but with millions of customers and a hundred support staff, it's just better avoided if possible. This logic also then needs to be built into other business support systems that rely on the customers IP/port range as an identifier.
LW46 solves this with a simple (though long) lookup table. This does mean that it's very easy to extract how a user is configured or identified with a minimum of additional knowledge and calculating tools.

cheers,
--satoru

------------------------------

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 26 Jun 2012 09:55:19 +0200

On 26 June 2012 09:13, <[email-masked]> wrote:

> From: Satoru Matsushima <[email-masked]>
> To: Peng Wu <[email-masked]>
> Cc: [email-masked], Yong Cui <[email-masked]>
> Message-ID: <[email-masked]>
> Not difficult, easy business for CE which implemented MAP. Other
> difficulty in operator side in particular provisioning complex, that should
> be same with LW46. It also makes to complete MAP spec in the ea-len zero
> case.
>
> [IF] Additional complexity in the operator side is where I see the problem
> with MAP in our case. The strength that MAP offers is for the mesh model
> and the complexity that it brings is a neat way of achieving this. But if
> hub-and-spoke is the only deployment scenario that you need, then the
> complexity for mesh is an unnecessary addition that results in operational
> complexity, which is something we're trying to engineer out wherever we can.
> E.g. In the case above, for a shared IP address, the source port range is
> encoded in the port-param option. To troubleshoot user connectivity, ops
> need to have a good understanding of how this is being calculated so that
> they can trace the user. Not the end of the world, but with millions of
> customers and a hundred support staff, it's just better avoided if
> possible. This logic also then needs to be built into other business
> support systems that rely on the customers IP/port range as an identifier.
> LW46 solves this with a simple (though long) lookup table. This does mean
> that it's very easy to extract how a user is configured or identified with
> a minimum of additional knowledge and calculating tools.
>

Well, a couple of observations:
A) MAP allows you to optimize complexity in not having to deal with per
subscriber rules in cases where this is feasible.
B) You're referring to data representation as an operational problem, which
if so, actually applies to any solution incl LW46 that transmits port-range
info to a client. I.e. "Whatever support staff" needs to be schooled to use
some logic to glean useful port information from the data sent to a client
C) It is very easy to represent MAP data as port range info on routers,
tools, etc.

-Woj.

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

---

From: Qiong <[email-masked]>
Date: Tue, 26 Jun 2012 23:11:45 +0800

Agree with Ian.

MAP is designed and optimized for algorithmatic address mapping, but not
for per-subscriber rule mapping. Actually, the more you would like to
solve, more complicated it will become.

I will certainly not buy MAP for per-subscriber case when MAP-T, MAP-E,
map-dhcp all becomes useless or not optimized. And I will not deploy
per-subscriber stateful and stateless solutions at the same.

So I encourage two seperated approaches optimized for different scenarios.
It will be good for both.

Do we really all forget about the "KISS" principle ?

Best wishes
Qiong

On Tue, Jun 26, 2012 at 3:55 PM, Wojciech Dec <[email-masked]> wrote:

> B) You're referring to data representation as an operational problem,
> which if so, actually applies to any solution incl LW46 that transmits
> port-range info to a client. I.e. "Whatever support staff" needs to be
> schooled to use some logic to glean useful port information from the data
> sent to a client

-- 
==============================================
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: Satoru Matsushima <[email-masked]>
Date: Wed, 27 Jun 2012 00:54:00 +0900

On 2012/06/27, at 0:11, Qiong wrote:

> Agree with Ian.
> 
> MAP is designed and optimized for algorithmatic address mapping, but not for per-subscriber rule mapping. Actually, the more you would like to solve, more complicated it will become.
> 
> I will certainly not buy MAP for per-subscriber case when MAP-T, MAP-E, map-dhcp all becomes useless or not optimized. And I will not deploy per-subscriber stateful and stateless solutions at the same. 
> 
> So I encourage two seperated approaches optimized for different scenarios. It will be good for both.
> 

Not quite.
I believe that the most motivate to start this work in the wg has destined MAP to be 'multi-protocol socket v2.0' that's what the former wg chair wished to. Do you remember that?

cheers,
--satoru

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 26 Jun 2012 17:38:49 +0000

Dear Satoru,

Did you propose the WG to revise the charter to add this work? I am sure
the current charter does not reflect this.

Regards,
Yiu

On 6/26/12 11:54 AM, "Satoru Matsushima" <[email-masked]>
wrote:

>'multi-protocol socket v2.0'

---

From: Maoke <[email-masked]>
Date: Wed, 27 Jun 2012 01:48:44 +0000

dear Satoru,

2012/6/26 Satoru Matsushima <[email-masked]>

> I believe that the most motivate to start this work in the wg has destined
> MAP to be 'multi-protocol socket v2.0' that's what the former wg chair
> wished to. Do you remember that?
>

i like the philosophy of "multi-protocol socket". however, i moderately
doubt the "multi-protocol socket v2.0" is a perfect plan for every cases.
in a quite good hotel, we see typically one 'multi-protocol socket' while a
lot of local-standard sockets. i never think it will make me happy if i see
every socket in my room is *multi-protocol*, occupying much spaces and
quite noticeable on the walls. we need one to deploy somewhere not the only
one type to deploy anywhere. ;-)

therefore i understand the motivation of the wg is making a unified
solution covering both encapsulation and translation in the framework of
stateless, WITHOUT the exclusiveness against other solutions, more
specifically suitable for a certain use case.

cheers,
maoke

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 27 Jun 2012 11:20:30 +0900

Hi Maoke,

On 2012/06/27, at 10:48, Maoke wrote:

> i like the philosophy of "multi-protocol socket". however, i moderately doubt the "multi-protocol socket v2.0" is a perfect plan for every cases. in a quite good hotel, we see typically one 'multi-protocol socket' while a lot of local-standard sockets. i never think it will make me happy if i see every socket in my room is *multi-protocol*, occupying much spaces and quite noticeable on the walls. we need one to deploy somewhere not the only one type to deploy anywhere. ;-)

That point would be an operational matter for deploying any standardized technology. For example, an operator adopt OSPF to use its rich routing feature but the network is small, the operator does just area 0 routing, even OSPF allow inter-area routing for scale. Is an another ospf specification needed for 'OSPF Area 0 Only Routing'?

> 
> therefore i understand the motivation of the wg is making a unified solution covering both encapsulation and translation in the framework of stateless, WITHOUT the exclusiveness against other solutions, more specifically suitable for a certain use case. 
> 

Studying each significant use case is quite important. I agree on that point with no doubt. However, is it IETF business for each use case specification?

cheers,
--satoru

---

From: Peng Wu <[email-masked]>
Date: Wed, 27 Jun 2012 11:36:01 +0800

> That point would be an operational matter for deploying any standardized technology. For example, an operator adopt OSPF to use its rich routing feature but the network is small, the operator does…

Well if I only have a simple network and I uses RIP, you don't make
OSPF somehow compatible with RIP(or just include RIP with an OSPF
terminology face? I don't know) and say "hey, just use this super
suite, don't consider it overloaded, it's for unity!"

---

From: Qiong <[email-masked]>
Date: Wed, 27 Jun 2012 11:49:45 +0800

Exactly. We will always choose the technique for its appropriate scenario.

On Wed, Jun 27, 2012 at 11:36 AM, Peng Wu <[email-masked]> wrote:

> >> > MAP is designed and optimized for algorithmatic address mapping, but
> not for per-subscriber rule mapping. Actually, the more you would like to
> >> > I will certainly not buy MAP for per-subscriber case when MAP-T,
> MAP-E, map-dhcp all becomes useless or not optimized. And I will not deploy
> >> I believe that the most motivate to start this work in the wg has
> destined MAP to be 'multi-protocol socket v2.0' that's what the former wg
> chair wished to. Do you remember that?
> >>
> > That point would be an operational matter for deploying any standardized
> technology. For example, an operator adopt OSPF to use its rich routing
> feature but the network is small, the operator does just area 0 routing,
> even OSPF allow inter-area routing for scale. Is an another ospf
> specification needed for 'OSPF Area 0 Only Routing'?
>
> > Studying each significant use case is quite important. I agree on that
> point with no doubt. However, is it IETF business for each use case
> specification?
> >
> > cheers,
> > --satoru
> >

Open source code:

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 27 Jun 2012 13:37:47 +0900

> suite, don't consider it overloaded, it's for unity!"

Oh, you don't argue that OSPF covers an use case which is also covered by RIP. So then why are you arguing that an use case of MAP is eventually same with the LW46 use case?

cheers,
--satoru

---

From: "Jiang Dong" <[email-masked]>
Date: Wed, 27 Jun 2012 14:34:16 +0800

Hi, Satoru,

I believe OSPF never abandon its own essence in order to be a super suite and do something very strange to cover the use case which can be easily and clearly done by RIP. 

What's more, MAP is not OSPF, and LW4over6 is not RIP. MAP and LW4over6 have their own use case when they are originally designed. MAP is not supposed to do the 1:1 mode in the beginning. 

Regards!
Jiang Dong

From: Satoru Matsushima
Date: 2012-06-27 12:37
To: Peng Wu
CC: softwires; ian.farrer
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG

cheers,
--satoru

---

From: Peng Wu <[email-masked]>
Date: Wed, 27 Jun 2012 14:38:03 +0800

> Oh, you don't argue that OSPF covers an use case which is also covered by RIP. So then why are you arguing that an use case of MAP is eventually same with the LW46 use case?
I'm clearly saying they have different use cases, but that's not the
point. Let me repeat. If I want RIP, you cannot just place RIP into
OSPF, put an OSPF "face" on it, and force me to use the OSPF "suite"
while the essence of the protocol I'm using is still RIP.

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 27 Jun 2012 15:57:40 +0900

On 2012/06/27, at 15:38, Peng Wu wrote:

> OSPF,

Agree on that it's not what I'm intended to. MAP thus never put DHCPv4 over IPv6, nor PCP into its specification. Please keep your mind in peace. 

> put an OSPF "face" on it, and force me to use the OSPF "suite"

Not to force, MAP uses its MAP protocol to an use case which also could be covered by LW46's DHCPv4 over IPv6, or PCP. Correct?

cheers,
--satoru

---

From: Peng Wu <[email-masked]>
Date: Wed, 27 Jun 2012 15:43:48 +0800

> Not to force, MAP uses its MAP protocol to an use case which also could be covered by LW46's DHCPv4 over IPv6, or PCP. Correct?
Yes, there are mutliple choices for the provisioning protocol. But the
essence here is 1.no v4-v6 address coupling, and thereby 2.explicitly
provisoin the v4 address and port set. I would say the ORIGINAL MAP
fits with neither points here.

BTW,  if I may, my suggestion on MAP to deal with the situation of EA
bit=0 is, just say in this case there is no algorithmic address
mapping so it's not consistent with general case or the original
motivation, and thereby not covered. I believe it is not the main
scenario you want to cover and this way you keep MAP clean.

---

From: Qiong <[email-masked]>
Date: Wed, 27 Jun 2012 15:52:53 +0800

Yes. And in ietf-map section1, it declares:

The residual IPv4 over IPv6 mechanisms must be capable of algorithmically
map between an IPv4 prefix, IPv4 address or a shared IPv4 address and an
IPv6 address

It is not consistent with EA-bit=0 case.

On Wed, Jun 27, 2012 at 3:43 PM, Peng Wu <[email-masked]> wrote:

> >>> Oh, you don't argue that OSPF covers an use case which is also covered
> by RIP. So then why are you arguing that an use case of MAP is eventually
> same with the LW46 use case?
> > Agree on that it's not what I'm intended to. MAP thus never put DHCPv4
> over IPv6, nor PCP into its specification. Please keep your mind in peace.
> >
> > Not to force, MAP uses its MAP protocol to an use case which also could
> be covered by LW46's DHCPv4 over IPv6, or PCP. Correct?
> >

Open source code:

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 27 Jun 2012 17:12:34 +0900

Qiong,

On 2012/06/27, at 16:52, Qiong wrote:

> The residual IPv4 over IPv6 mechanisms must be capable of algorithmically map between an IPv4 prefix, IPv4 address or a shared IPv4 address and an IPv6 address
> 

Not true. Whether ea-len is zero or not, when a rule-ipv6-prefix in a BMR is exact matched with a CE's prefix, it must be legitimate that provisioning the CE to have rule-ipv4-prefix and the PSID in the BMR.

cheers,
--satoru

> lightweight 4over6: http://sourceforge.net/projects/laft6/
> PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 27 Jun 2012 17:25:12 +0900

> scenario you want to cover and this way you keep MAP clean.

Thank you for your technical suggestion. 
But it couldn't be an option because MAP node finds its BMR in longest match basis between end-user ipv6 prefix and the rule-ipv6-prefix whether the ea-len is zero or not in the BMR.

FWIW, my suggestion is that LW46 adopts MAP provisioned CE to be a kind of TI which connected to a TC.

cheers,
--satoru

---

From: <[email-masked]>
Date: Wed, 27 Jun 2012 10:39:41 +0200

Hi Woj,

Comments in line.

Cheers,
Ian

________________________________
From: Wojciech Dec [mailto:[email-masked]]
Sent: Dienstag, 26. Juni 2012 09:55
To: Farrer, Ian
Cc: [email-masked]; [email-masked]
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG

On 26 June 2012 09:13, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Satoru,

Comment in line below.

Best regards,
Ian

Hi Peng,

Well, a couple of observations:
A) MAP allows you to optimize complexity in not having to deal with per subscriber rules in cases where this is feasible.

But this re-introduces v4 and v6 addressing dependency which we're trying to avoid.

B) You're referring to data representation as an operational problem, which if so, actually applies to any solution incl LW46 that transmits port-range info to a client. I.e. "Whatever support staff" needs to be schooled to use some logic to glean useful port information from the data sent to a client

"Don't worry about unnecessary complexity, we'll just do more training!" isn't a very powerful argument in our business.

C) It is very easy to represent MAP data as port range info on routers, tools, etc.

On routers, I'm sure that it is. However, the fact that you need a tool to work out the mapping again points to complexity. On internally developed and 3rd party BSS systems then it's more work that offers no benefit.

-Woj.

cheers,
--satoru

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

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 27 Jun 2012 10:53:45 +0200

Ian,

On 27 June 2012 10:39, <[email-masked]> wrote:

> **
> *From:* Wojciech Dec [mailto:[email-masked]]
> *Sent:* Dienstag, 26. Juni 2012 09:55
> *To:* Farrer, Ian
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT
> reflect the consensus from the WG
>
>
>
>> [IF] Additional complexity in the operator side is where I see the
>> problem with MAP in our case. The strength that MAP offers is for the mesh
>> model and the complexity that it brings is a neat way of achieving this.
>> But if hub-and-spoke is the only deployment scenario that you need, then
>> the complexity for mesh is an unnecessary addition that results in
>> operational complexity, which is something we're trying to engineer out
>> wherever we can.
> "Don't worry about unnecessary complexity, we'll just do more training!"
> isn't a very powerful argument in our business.
>

Woj> You appear to forget that your support staff using L46 needs to be
trained. There is no difference in the amount of training

> On routers, I'm sure that it is. However, the fact that you need a tool to
> work out the mapping again points to complexity. On internally developed
> and 3rd party BSS systems then it's more work that offers no benefit.
>

Woj> Tool = packet sniffer, whatever. I'll assert that you cannot decode
L46 options without specialised tooling.

Cheers,
Woj.

---

From: xiechf01 <[email-masked]>
Date: Wed, 27 Jun 2012 17:17:57 +0800

We admit the algorithmic mapping is technically and theoretically "beautiful", multiple mapping methods and forwarding modes have been designed. 
The essence of this mapping is that the format of IPv6 packet depends on IPv4 address and port information, with an algorithmic pre-determined  relationship in it. However, when deciding whether to adopt it in the future,the following aspects should be considered first.

1) With algorithmic mapping method, some of bits in IPv6 prefix will be utilized by IPv4 address(or part of IPv4 address),   which means that these  bits 
can not be used for other purpose. Since the number of bits of IPv6 prefix allocated to a given ISP is limited, every bit should be treated carefully. 
When ISP deploys IPv6 in product network,some other features including service type, QoS, location, etc,may also be taken into consideration and embedded
 in IPv6 prefix,which might conflict with EA-bits.

2) Algorithmic mapping needs the engineering staff of local NOC to understand complex mapping algorithm, different mapping modes, forwarding modes,
 etc, which means they must be smart enough. Address planning and allocation is an important job of NOC, and it requires NOC guys to master all these stuff 
to operate network correctly. But we will ask honestly, do our effort deserve such complexity?

From operators' perspective, we hope that the address format should have less constraint and more flexibility. IPv6 is born for IPv6, not for IPv4. We can have 
more freedom the utilize the IPv6 address, more flexibility, easy understanding and management feature.

Yes, MAP can provide a per-subscriber per-rule mode when the length of EA-bits becomes zero somehow. But this means the mapping feature is removed in this case. But then we will ask, if the mapping is already gone, why should we 
buy so many useless features to do this?   

“The simpler, the better”，that's what we want.

Chongfeng @China Telecom

From: [email-masked]
Date: 2012-06-27 16:39
To: [email-masked]
CC: softwires
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG
Hi Woj,

Comments in line.

Cheers,
Ian

Hi Satoru,

Comment in line below.

Best regards,
Ian

Hi Peng,

 

-Woj.

cheers,
--satoru

---

From: Qi Sun <[email-masked]>
Date: Wed, 27 Jun 2012 17:20:26 +0800

Hi Satoru,

Please see inline.

BTW, my name is Qi :)

Qi Sun

On Wed, Jun 27, 2012 at 4:37 PM, Satoru Matsushima <
[email-masked]> wrote:

> Hi Qiong,
>
> On 2012/06/27, at 16:54, Qi Sun wrote:
>
> > Hi Satoru,
> >
> > Please see inline.
> >
> > Qi Sun
> >
> > On Wed, Jun 27, 2012 at 2:57 PM, Satoru Matsushima <
> [email-masked]> wrote:
> >
> > >> Oh, you don't argue that OSPF covers an use case which is also
> covered by RIP. So then why are you arguing that an use case of MAP is
> eventually same with the LW46 use case?
> > [Qi] That's not what the thread is discussing. Please do not try to
> change the topic.
> >
>
> Not intended.
>
> > [Qi] Do you mean MAP can do all these things WITHOUT ANY help from other
> documents, saying DHCPv6 options?
>
> Ah, ok. MAP define mapping rule as its protocol. DHCPv6 is a bearer of
> mapping rules.
>

[Qi]  What we are discussing is on the essence of MAP where 1:1 mode is
intended to import binding table on BR , and on whether the ietf-map-00 is
qualified as a WG draft without consensus of the softwire WG. Rather than
the provisioning methods, saying DHCPv4 over IPv6 or DHCPv6 options.

>
> >  All those mechanisms like DHCPv4 over IPv6 or PCP are not the essence
> of the protocol but provisioning method for LW4over6.
> > Actually, based on what you have said, I can get that the "new" MAP can
> achieve its NEW added 1:1 mode with the help of DHCPv4 over IPv6 for IPv4
> address allocation. Why don't you use it, which has been a DHC WG draft?
> >
>
> These are not possible because they require state in BR so that it's LW46
> use case, right? MAP define mapping rule in stateless manner.
>

[Qi] As a provisioning method, DHCPv4 over IPv6 DOES NOT require any state
in TC/BR. Please check the draft. As a result, this is not about stateful
or stateless. There is no conflict between the binding table on BR and the
DHCPv4 over IPv6 process.

---

From: Tetsuya Murakami <[email-masked]>
Date: Wed, 27 Jun 2012 09:31:12 +0000

Hi Peng,

I think it is just example. 

In case of this example, I think the standard of OSPF can't allow to use it for only inter-area routing. This standard can also allow to use it within only area 0. I think sometimes multiple solutions could be applied to solve the same problem. In case of this example, either OSPF or RIP could be applied.

BTW, based on MAP draft, I think MAP can always keep the stateless mapping between ipv4 prefix, ipv4 address or a shared ipv4 address and an ipv6 address. It does not depend on the length of ea-bit. Even though ea-bit length is zero, rule ipv6 prefix is totally matched to the delegated prefix to CE and also ipv4 address based on rule ipv4 prefix can be associated with the ipv6 address based on the mapping rule. For this, I think MAP can keep the mapping functionality between ipv4 and ipv6 even though ea-bit length is zero.

Thanks,
Tetsuya

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 27 Jun 2012 18:32:19 +0900

> BTW, my name is Qi :)

Agh! I'm so sorry!

> 
> [Qi]  What we are discussing is on the essence of MAP where 1:1 mode is intended to import binding table on BR , and on whether the ietf-map-00 is qualified as a WG draft without consensus of the softwire WG. Rather than the provisioning methods, saying DHCPv4 over IPv6 or DHCPv6 options.
> 

Ah, ok.

> >  All those mechanisms like DHCPv4 over IPv6 or PCP are not the essence of the protocol but provisioning method for LW4over6.
> > Actually, based on what you have said, I can get that the "new" MAP can achieve its NEW added 1:1 mode with the help of DHCPv4 over IPv6 for IPv4 address allocation. Why don't you use it, which has been a DHC WG draft?
> >
> 
> These are not possible because they require state in BR so that it's LW46 use case, right? MAP define mapping rule in stateless manner.
> 
> [Qi] As a provisioning method, DHCPv4 over IPv6 DOES NOT require any state in TC/BR. Please check the draft. As a result, this is not about stateful or stateless. There is no conflict between the binding table on BR and the DHCPv4 over IPv6 process.

If it is true, LW46 should be a stateless solution.

cheers,
--satoru

---

From: Qi Sun <[email-masked]>
Date: Wed, 27 Jun 2012 18:01:58 +0800

Hi Satoru,

Inline, please ;)

Qi Sun

On Wed, Jun 27, 2012 at 5:32 PM, Satoru Matsushima <
[email-masked]> wrote:

> > > Actually, based on what you have said, I can get that the "new" MAP
> can achieve its NEW added 1:1 mode with the help of DHCPv4 over IPv6 for
> IPv4 address allocation. Why don't you use it, which has been a DHC WG
> draft?
> > >
> >
> > These are not possible because they require state in BR so that it's
> LW46 use case, right? MAP define mapping rule in stateless manner.
> >
> > [Qi] As a provisioning method, DHCPv4 over IPv6 DOES NOT require any
> state in TC/BR. Please check the draft. As a result, this is not about
> stateful or stateless. There is no conflict between the binding table on BR
> and the DHCPv4 over IPv6 process.
>
> [Qi] DHCPv4 over IPv6 is a provisioning method. And it's about the public
IPv4 address allocation, NOT about IPv4 address and IPv6 address mapping.
So there is no state. Please read the draft of DHCPv4 over IPv6 for
clarification.
LW4over6 needs to maintain the binding table on TC. That's stateful.
Actually in MAP 1:1 mode there will be a binding table right? Here comes
the question: what will you do if there are new comers or some users
leaving the network?

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 27 Jun 2012 19:27:28 +0900

Qi,

On 2012/06/27, at 19:01, Qi Sun wrote:

> 
> [Qi] DHCPv4 over IPv6 is a provisioning method. And it's about the public IPv4 address allocation, NOT about IPv4 address and IPv6 address mapping. So there is no state. Please read the draft of DHCPv4 over IPv6 for clarification.

That sense is 'stateless' in my mind if there's no DHCP state in the BR. 

> Actually in MAP 1:1 mode there will be a binding table right? Here comes the question: what will you do if there are new comers or some users leaving the network?

it is just an operation in provision. Now I find that LW46 could be possible to merged with MAP, or vice versa. thanks.

cheers,
--satoru

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 27 Jun 2012 13:30:06 +0200

Hello Chongfeng,

On 27 June 2012 11:17, xiechf01 <[email-masked]> wrote:

> The essence of this mapping is that the format of IPv6 packet depends on IPv4 address and port information, with an algorithmic pre-determined
> relationship in it. However, when deciding whether to adopt it in the future,the following aspects should be considered first.
>
> When ISP deploys IPv6 in product network,some other features including service type,
> QoS, location, etc,may also be taken into consideration and embedded

MAP uses EA-bits, but the source of those EA-bits can be almost any. In
cases where the EA-bits derive from the v6 prefix, this leads to actually a
significant reduction in the number of rules that need to be provisioned in
a domain - this simplifies operations hugely. The location of the EA-bits
in the prefix is also flexible.
That said, the EA-bits can derive from any piece of configuration
information, and this does NOT have to be the IPv6 prefix. This leads to
per CE rules, and effectively more complex operations.
It is thus a question of optimization and simplicity vs a lock-in to an
"impossible" to optimize architecture.

> to operate network correctly. But we will ask honestly, do our effort deserve such complexity?
Well, there is nothing difficult in the mapping algorithm; it maps port
ranges to CEs. All solutions in this space do just that.
I do not believe that complexity can be attributed to the use of a
Port-Set-ID, vs the use of explicit port ranges in some dhcp option. Even
"light" NOC staff would need to be schooled in interpreting such data. I'll
levae aside the complex chain of events that is necessary to put into place
to make the L46 solution in place

> “The simpler, the better”，that's what we want.

Many years of network experience have shown that solutions which rely
per-CPE/subscriber provisioning or state on network devices are ultimately
anything but simple or robust - that does not stop people from re-inventing
the BRAS, etc. That said, building such intricate stateful solutions, with
no possibility for optimization is anything but simpler or better.
Ironically a unified & comprehensive solution is possible here. Hopefully
we'll converge on that soon, but that requires some more open discussion.

Regards,
Woj.

>
> Chongfeng @China <Chongfeng@China> Telecom
>
>
>  *From:* [email-masked]
> *Date:* 2012-06-27 16:39
> *To:* [email-masked]
> *CC:* softwires <[email-masked]>

---

From: Qi Sun <[email-masked]>
Date: Wed, 27 Jun 2012 19:42:16 +0800

Hi Satoru,

Please see inline :)

Qi Sun

On Wed, Jun 27, 2012 at 6:27 PM, Satoru Matsushima <
[email-masked]> wrote:

> > [Qi] DHCPv4 over IPv6 is a provisioning method. And it's about the
> public IPv4 address allocation, NOT about IPv4 address and IPv6 address
> mapping. So there is no state. Please read the draft of DHCPv4 over IPv6
> for clarification.
> [Qi] What discussed here is about states on data plane, aka the v4-v6
addressing binding(please refer to joel's email). The binding table could
be dynamic(on-demand) or static.

> it is just an operation in provision. Now I find that LW46 could be
> possible to merged with MAP, or vice versa. thanks.
>

[Qi] LW4over6 is a solution targeting at the per-user stateful/binding
scenario, pure and clear.
MAP is originally targeting at pure stateless/alogrithmic address
mapping scenario, and then comes
to this 1:1 mode due to the theoretical corner case of EA-bits=0,
according to you guys.
While I believe the main targets are differnt and paralled
(actually two out of three in 4-over-6 case,
with the 3rd one per-session stateful), I don't think merging is the
proper way to proceed.

Thanks,
Qi

---

From: Tom Taylor <[email-masked]>
Date: Wed, 27 Jun 2012 08:21:07 -0400

An old cartoon I once saw, making fun of ISDN IIRC, showed a single 
socket on the outside of the wall, connected to a rat's-nest of 
connections on the inside. This seems apt for the present enterprise.

Tom Taylor

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 27 Jun 2012 22:32:16 +0900

> > [Qi] As a provisioning method, DHCPv4 over IPv6 DOES NOT require any state in TC/BR. Please check the draft. As a result, this is not about stateful or stateless. There is no conflict between the…

OK.
But wait, if it's not about stateful or stateless, the DHCPv4 over IPv6 could also be a means to provision MAP CEs in a domain which is not only per-sub mapping rule case, but also in the case of all MAP CEs covered by single mapping rule. Great.

How we are in well collaboration! Thanks a lot.

cheers,
--satoru

---

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 27 Jun 2012 16:36:35 +0200

> connections on the inside. This seems apt for the present enterprise.
Regarding cartoons, I believe this one is relevant as well:

http://xkcd.com/927/

Cheers,
Tomek

---

From: Leaf yeh <[email-masked]>
Date: Wed, 27 Jun 2012 15:05:07 +0000

http://xkcd.com/449/ - Just for a test

________________________________
From: [email-masked] [[email-masked]] on behalf of Tomek Mrugalski [[email-masked]]
Sent: Wednesday, June 27, 2012 22:36
To: [email-masked]
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG

http://xkcd.com/927/

Cheers,
Tomek

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 27 Jun 2012 10:23:18 -0500

This is a moot argument, as we have seen many protocols (take MPLS for
example) that were proposed to do just X, evolved to do X, Y, Z and
more.

Who would have thought that BGP would be advertising MAC addresses when
BGP was first introduced?

Let's focus on the operational problems solved (or not solved) by any of
our solution sets. I appreciate Ian's email in that light. This will
help us evolve our solution sets and have us spend our time in the right
direction.

Cheers,
Rajiv

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Jiang Dong
> Sent: Wednesday, June 27, 2012 2:34 AM
> To: Satoru Matsushima; Peng Wu
> Cc: Softwires WG; ian.farrer
> I believe OSPF never abandon its own essence in order to be a super
suite
> and do something very strange to cover the use case which can be
easily and
> clearly done by RIP.
> 
> What's more, MAP is not OSPF, and LW4over6 is not RIP. MAP and
LW4over6
> have their own use case when they are originally designed. MAP is not
> supposed to do the 1:1 mode in the beginning.
> 
> Regards!
> Jiang Dong
> 
> From: Satoru Matsushima <mailto:[email-masked]>
> Date: 2012-06-27 12:37
> To: Peng Wu <mailto:[email-masked]>
> CC: softwires <mailto:[email-masked]> ; ian.farrer
> <mailto:[email-masked]>
NOT
> reflect the consensus from the WG On 2012/06/27, at 12:36, Peng Wu
wrote:
> >>> i like the philosophy of "multi-protocol socket". however, i
> >>> moderately doubt the "multi-protocol socket v2.0" is a perfect
plan
> >>> for every cases. in a quite good hotel, we see typically one
> >>> 'multi-protocol socket' while a lot of local-standard sockets. i
> >>> never think it will make me happy if i see every socket in my room
> >>> is *multi-protocol*, occupying much spaces and quite noticeable on
> >>> the walls. we need one to deploy somewhere not the only one type
to
> >>> deploy anywhere. ;-)
> >>
> >> That point would be an operational matter for deploying any
> standardized technology. For example, an operator adopt OSPF to use
its
> rich routing feature but the network is small, the operator does just
area 0
> routing, even OSPF allow inter-area routing for scale. Is an another
ospf
> Oh, you don't argue that OSPF covers an use case which is also covered
by
> RIP. So then why are you arguing that an use case of MAP is eventually
same
> with the LW46 use case?

---

From: "Jiang Dong" <[email-masked]>
Date: Thu, 28 Jun 2012 09:57:32 +0800

Hi,

Then I will ask: Have the Y, Z already been hard worked by some other guys for a long time?

I don't think what you said is the right direction. What I can see from the mailing list is that the MAP-00 authors were trying to avoid some critical questions.

Yes the technical details can be discussed, but this is not the right time to do this before a clear clarification is made. 

Regards!
Jiang Dong

From: Rajiv Asati (rajiva)
Date: 2012-06-27 23:23
To: jiangdong345; Satoru Matsushima; Peng Wu
CC: Softwires WG; ian.farrer
Subject: RE: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOTreflect the consensus from the WG
This is a moot argument, as we have seen many protocols (take MPLS for
example) that were proposed to do just X, evolved to do X, Y, Z and
more.

Cheers,
Rajiv

On
suite
easily and
LW4over6
NOT
plan
to
its
area 0
ospf
by
same

---

From: Qi Sun <[email-masked]>
Date: Thu, 28 Jun 2012 13:01:43 +0800

Hi Satoru,

In addition to my previous email (not the one you last replyed): DHCPv4
over IPv6 will create/refresh the per-subscriber state. And LW4over6
features to keep it dynamic(on demand).

Thanks,
Qi

On Wed, Jun 27, 2012 at 7:42 PM, Qi Sun <[email-masked]> wrote:

>> > Actually in MAP 1:1 mode there will be a binding table right? Here
>> comes the question: what will you do if there are new comers or some users
>> leaving the network?
>>
> [Qi] LW4over6 is a solution targeting at the per-user stateful/binding scenario, pure and clear.
> MAP is originally targeting at pure stateless/alogrithmic address mapping scenario, and then comes
> to this 1:1 mode due to the theoretical corner case of EA-bits=0, according to you guys.
> with the 3rd one per-session stateful), I don't think merging is the proper way to proceed.
>
> Thanks,
> Qi
>
>>
>> cheers,
>> --satoru
>
>
>