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

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