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

[Wojciech Dec <[e-mail]>]

Hello Chongfeng,

On 27 June 2012 11:17, xiechf01 <[e-mail]> wrote:

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

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.

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

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

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