Ian, On 27 June 2012 10:39, <[email protected]> wrote:
> ** > 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. > 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires >> >> >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
