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

Ian,

On 27 June 2012 10:39, <ian.farrer@telekom.de> wrote:

> **
> Hi Woj,
>
> Comments in line.
>
> Cheers,
> Ian
>
>  ------------------------------
> *From:* Wojciech Dec [mailto:wdec.ietf@gmail.com]
> *Sent:* Dienstag, 26. Juni 2012 09:55
> *To:* Farrer, Ian
> *Cc:* satoru.matsushima@gmail.com; softwires@ietf.org
> *Subject:* Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT
> reflect the consensus from the WG
>
>
>
> On 26 June 2012 09:13, <ian.farrer@telekom.de> wrote:
>
>>   Hi Satoru,
>>
>> Comment in line below.
>>
>> Best regards,
>> Ian
>>
>> Date: Mon, 25 Jun 2012 18:46:18 +0900
>> From: Satoru Matsushima <satoru.matsushima@gmail.com>
>> To: Peng Wu <pengwu.thu@gmail.com>
>> Cc: softwires@ietf.org, Yong Cui <cuiyong@tsinghua.edu.cn>
>>  Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does
>> NOTreflect the consensus from the WG
>> Message-ID: <5851B29B-0CCF-4B08-86D5-8CBBFCEF5FA4@gmail.com>
>> 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.
>

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

>
> 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> Tool = packet sniffer, whatever. I'll assert that you cannot decode
L46 options without specialised tooling.

Cheers,
Woj.

>
> -Woj.
>
>
>>
>> cheers,
>> --satoru
>>
>> ------------------------------
>>
>>
>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>>
>>
>