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

[Gyan Mishra <[e-mail]>]

Hi Ole

Responses in-line

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

> > With 5G network slicing will become a formidable part of the paradigm
> shift from shared resources to network resource isolation at the radio and
> RAN layers.  The use case for being able to provide critical segmentation
> for network slices makes it an industry imperative to be able support
> variable IID lengths with slaac as all 5G deployments worldwide will be
> IPv6 only from the start.
>
> You'd likely find most people on this group thinking of 5G as just "more
> of the same"; access to the Internet.
> At least I struggled understanding what there is about 5G that would
> require a change in IPv6 addressing models.


  Gyan> With 5G you have mobile handset 5G and fixed 5G that would replace
broadband.  So the fixed 5G would be subject to BCOP RIPE-690 and
recommendations for /56 allocations just as with broadband and maybe bigger
allocations for network slicing.  The big change with 5G 10G cell bandwidth
is the concept of network slicing.  So today 4G front hall is handset to
cell tower and then RAN radio VPN is a single VPN backhaul to the core and
out to the internet.  So with 5G the concept of network slicing is the big
change as you have 10G bandwidth to the mobile device.  So the the mobile
handset would sit on a regular VPN network slice that is SR-TE steered over
the core.  So network slicing does not have any impact on the handset as it
sits on a single BAU normal RAN backhaul VPN.

So I was mistaken that that handset network slicing /64 segmentation is an
issue with 5G. The concept of network slicing framework is on the fronthaul
mobile to cell tower and backhaul cell tower to core, so here as far as
this draft, network slicing as that is seamless to the mobile handset does
not impact this draft as far as /64 segmentation.

However, the issue mentioned in the problem statement draft with
segmentation with 4G, the same issue exists with 5G on the customer network.

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

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/


>
> Best regards,
> Ole

-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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