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 protected]
Date: 2012-06-27 16:39
To: [email protected]
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
From: Wojciech Dec [mailto:[email protected]]
Sent: Dienstag, 26. Juni 2012 09:55
To: Farrer, Ian
Cc: [email protected]; [email protected]
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect
the consensus from the WG
On 26 June 2012 09:13, <[email protected]> wrote:
Hi Satoru,
Comment in line below.
Best regards,
Ian
Date: Mon, 25 Jun 2012 18:46:18 +0900
From: Satoru Matsushima <[email protected]>
To: Peng Wu <[email protected]>
Cc: [email protected], Yong Cui <[email protected]>
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does
NOTreflect the consensus from the WG
Message-ID: <[email protected]>
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.
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 protected]
https://www.ietf.org/mailman/listinfo/softwires_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
