Re: [v6ops] RFC7849 must not recommend 64share, and must not be recommended itself to 3GPP

[Ca By <[e-mail]>]

On Fri, Mar 3, 2017 at 9:10 AM Alexandre Petrescu <
[e-mail]> wrote:

> Le 03/03/2017 à 17:09, Ca By a écrit :
> >
> > On Fri, Mar 3, 2017 at 5:54 AM Alexandre Petrescu
> > <[e-mail] <mailto:[e-mail]>>
> >  wrote:
> >
> >
> >
> > Le 03/03/2017 à 14:43, Erik Kline a écrit :
> >>
> >> Because Prefix Delegation capabilities may not be available in
> >> some attached networks, L_REC#1 is strongly recommended to
> >> accommodate early deployments. =====
> >>
> >>
> >> This is wrong.  We should _never_ recommend somehting we know it
> >> does not scale.  64share does not scale, there is a 'multi-link
> >> subnets' RFC and there is operational experience showing so.
> >>
> >>
> >> False.
> >>
> >> We wrote IPv6 tethering in Android N (MR1), it uses 64share, and
> >> it pretty much works just fine.
> >
> > Works fine but does is scale?
> >
> >
> > Yes, millions of users
>
> Well, I did not ask about scaling in terms of how many times can you
> copy the same software on how many devices, or how many human users can
> buy smartphones from same operator.  I agree 64share (like most other
> sw) can scale to millions of devices sold to millions of users as part
> of some subscription plans.
>
> I asked about scaling in terms of IP networking.
>
> I dont want _your_ network to grow, I want the end user's network to
> grow.  And your network must not prevent the end user's network from
> growing.
>
> 64share prevents your end users' networks from growing.
>
> So, while millions of users is good, I look more at like billions of
> devices connected to these millions of users.
>
> > (apple and android) on many networks use what is described in
> > 64share.
>
> It is good that apple and android implement that software.
>
> But that alone does not make it more recommendable than a plethora of
> other software, starting from the simplest 'Hello World'.
>
> > 64share describes 100% of the cases where users get ipv6 addresses
> > via 3gpp phone tether afaik.
>
> Yes, 64share RFC describes use-cases where it's relevant.
>
> But I guess, as you write below about bicycles, 64share does not
> care about, well, bicycles.
>
> And the bicycles are different than smartphones.
>
> As such, I dont understand why pushing 64share into 3GPP, when 3GPP
> cares not only about smartphones, but also about IoTs like bicycles.
>
> As such, I dont understand why making 64share into a recommendation to
> 3GPP.
>
> More refinement should be there.
>
> > Spare me the discussion about how the dongle ....
>
> Well - you dont care about dongles, I do.
>
> I will spare you.
>
> But you will have to change the way you think of your end users.  They
> wont spare you about their dongles, M2M devices and other IoTs.
>
> > I am unaware of any network or mainstream smartphone that supports
> > dhcp-pd.
>
> Dont you think that the question of whether or not DHCP-PD runs ok on
> smartphone is irrelevant?  DHCP-PD is open source software, can compile
> anywhere.
>
> Assume DHCPv6-PD app runs ok on smartphone.
>
> And that does not make the operator respond and deliver prefixes.  They
> dont care about a smartphone running or not the DHCPv6-PD.  They care
> about what 3GPP asks.  And 3GPP asks what this RFC says.  And this RFC
> says no need of DHCP because do 64share.  That's not normal.
>
> > I am sure you can rig something up, but i am simply referring to your
> > comment of scale in the real world for todays use cases.
>
> Ah, let me clarify my comment of scale.
>
> I am concerned with scaling beyond 2 subnets: up to 45 subnets in 15
> cars, and 10 subnets in 5 Road-Side Units, in a city center area.  And
> that's the lowest number I could go with.
>
> 64share cant scale to that.  Do you agree?
>
> This may be 'rigging up' for you, but for me it is more serious.
>
> > This is ietf, running code matters. Deployments matter even more.
>
> I agree.
>
> But in this case it seems what you believe your smartphone deployment
> should prime over what non-smartphone (e.g. bicycle) deployments need.
>
> > Bike shed colors do not matter, bike shed colors for flying bike to
> > bike communication is an interesting topic,
>
> I agree with you that communicating bicycles may sound a far-fetched
> scenario to some, but I also agree with hundreds of people working
> precisely on the topic of communicating bicycles.  It saves lives.
>
> The fact that you discard that as some 'flying' objects, presumably
> assuming they are only on the drawing board, is not very kind.  Please
> stop that.
>
> Please do not be ignorant with topics that are important to others.
>
> Moreover, I invite you to come and see the next demo events.
>
> > but I suggest you avoid calling the current bike shed a failure and
> > keeping its deployment reality a dirty secret.
>
> I do not understand what you mean, but I want to let you know that I did
> work on connecting a Parking (including bike shed) to the IPv6 Internet.
>
> I dont understand what you mean by 'keeping its deployment reality a
> dirty secret'.  The deployments I work often get publicized in public
> media and events.
>
> > We tried that with nat44, it did not turn out well.
>
> We agree on NAT is evil, but I dont understand: do you threaten with it?
> I dont understand that here.
>
> If we discuss threats, here is my reply:
>
> It's now the 64share argument killing DHCP-PD at 3GPP that MAY make me
> make a second deployment with NAT66.
>
> Were 64share to be less all-encompassing in its claims, DHCPv6-PD may
> get in a stronger recommendation document to RFC, then to 3GPP and then
> to operators.
>
> Alex
>
> >
> > CB
> >
> >
> >
> >
> >> It is tricky if you want to further delegate from there,
> >
> > That 'tricky' scares me, really.
> >
> >> but works A-OK for its stated intended purpose.
> >
> > If its intended purposes are that 'deployments require 64 sharing',
> > as RFC7849 puts it, please let me say I have strong doubts.
> >
> > If the intended purpose is "make one or two WiFi hotspots on a
> > smartphone" - then say so everywhere.  Do not generalise, or falsely
> > induce people into thinking 64share can be used to anything more than
> > just that.
> >
> > Do not put this 64share into 3GPP specs.  Do not put this 64share
> > into IETF documents having '3GPP' in their titles.
> >
> > It's as if I put my preferred 'Hello World' software in 3GPP specs.
> > True, it runs on a smartphone, but what more could 3GPP care about
> > it.
> >
> > 3GPP does much more about extendign networks at the edges than just
> > one or two wifi hotspots on a smartphone.  64share does not scale to
> >  that.
> >
> > But let me ask: what is the intended purpose of 64share from your
> > point of view?
> >
> > Alex
> >


Alex -- i suggests you re-read 64share to discover its intended purpose.

For your convenience, i provide this quote from it.

"DHCPv6 is the best way to delegate a prefix to a LAN link. The

   methods described in this document SHOULD only be applied when
   deploying DHCPv6 Prefix Delegation is not achievable in the 3GPP
   network and the UE.

"

So telling anyone about 64share is by association telling them dhcp-pd is
best.

Dhcp-pd will be deployed as soon as the business case justifies it, 64share
is a single LAN stop gap.

 Your issue is simply one of supply and demand. No ietf or 3gpp document is
lacking specification for making dhcp-pd happen.





> > _______________________________________________ v6ops mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/v6ops
> >
>