Re: I-D Action: draft-mishra-6man-variable-slaac-01.txt

[Gyan Mishra <[e-mail]>]

On Wed, Nov 4, 2020 at 3:45 AM <[e-mail]> wrote:

> Gyan,
>
> > Are there any of the problems/use-cases that cannot be solved by
> assigning a shorter prefix than /64 to the end-user networks?
> >
> >    Gyan> The issue here with 4G providers to be able to force providers
> to go with a shorter prefix is impossible and similar to the issue we see
> with the v6ops flash renumbering issue and even in light of BCOP RIPE-690
> that broadband operator’s PD allocations is /64 and not /56 as recommended
> in BCOP and due to the impact of flash renumbering events we are now
> changing the VL PL to short timers to age our the stale prefix during a
> renumbering event.  So the standard on 4G and as it is the same standard
> for 5G handsets allocation, a /64, and 4G and even 5G operators for mobile
> handset provisioning do not plan to make it a shorter prefix.  So either
> customers end up suffering with flash renumbering events or you update the
> standard.  Same issue we are faced with here with wireless providers and
> forcing them to dole out shorter prefix.
>
> I don't understand the coupling you make between the 64 bit boundary and
> flash renumbering.


   Gyan> This was an apples versus oranges analogy not comparison.  So to
clarify what I was trying to say is that with flash renumbering issue
instead of putting the onus on the service provider to fix the issue with
flash renumbering to broadband customers we are changing the standards now
to use very short 2 hour timers for VL and PL.  Similarly as an analogy it
will be very difficult to get 3GPP 4G and 5G mobile handset scenario to
change to provide shorter prefix.  The standard is a /64 allocation to
mobile handsets and that will more than likely remain and not change

>
>
> > Fixed 5G replacement for broadband I mentioned, not to be confused with
> 5G mobile handset, would follow BCOP RIPE-690 and I believe will go in with
> larger allocation like a /56 or larger.  So the fixed 5G network slicing
> how it comes into play as a value proposition and massive benefit to
> customers, is it can now have the front haul 5G to tower and back haul
> tower to core now be provisioned to the fixed 5G with a normal BAU slice
> template for normal traffic and at the same time separate slices for
> special Enhanced VPN over SRv6 core SR-TE steered with dedicated resources
> and traffic  isolation and special QoS prioritization for applications such
> as IOT, E911 emergency services, or utilities etc.
> >
> >
> https://www.internetsociety.org/blog/2017/10/ipv6-prefix-assignment-bcop-published-ripe-690/
>
> OK, so the problem is:
> "How do you connect an end-user network with multiple links to a provider
> who only allocates a /64 to the site.".
>
> There is a conundrum here. A reason for the 64-bit boundary is that it
> forces the provider to give at least a /64.
> That design decision seems to have had the intended effect. You don't see
> any providers assigning less address space than the /64.
>
> If we were to relax that limitation, then there is a fear that providers
> will start assigning fewer addresses to end-users. Down to a single address
> like we see in IPv4.
>
> The conundrum then is:
> How do we ensure providers allocate at least a /64 of address space to
> end-users, and at the same time allow end-users to extend a network with
> only a /64 assigned to it.
>
> Answer that and we can make progress.


   Gyan>


As a representative SME of Verizon a tier 1 service provider and one of the
largest wireless carriers worldwide I can make a guarantee that it won’t
change  and if Verizon made the /64 allocation part of our marketing
strategy that would deter any other operators from wanting to go with
longer prefixes as they would loose business.  As a tier 1 we can work with
the other major carriers we have partnership with to garner support among
the largest wireless providers.

We could also write an RFC BCOP that the minimum requirement allocation is
a /64 and that operators must abide by that.

We could also develop a RIPE doc and publish with ISOC that mandates the
standard as well as work with all operator groups worldwide to ensure they
abide by the BCOP.

Another point is the OPEX overhead costs of management and maintenance of
vlsm to customers which is had to be accounted for 0 monetary gain for the
additional OPEX costs versus /64 size to all customers.

I would say of all the points above in addition, operators are driven just
as any business by monetary gain and what is the bottom line ROI.  If the
answer is 0 why change from a /64 allocation.  As the IPv6 allocations for
providers is leaps and bounds way more massive as compare to IPv4, there is
not any address space saving that could be gained which could translate
into ROI to go with a smaller than /64 allocation.

>
>
> Best regards,
> Ole

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD