Re: Has virtualization become obsolete in 5G?

[Mark Tinka]

On 5/Aug/20 18:34, Etienne-Victor Depasquale wrote:

>
> Release 16 is just out and if it has delivered the 5G vision, 
> latency between devices connected over the same radio interface 
> (which I take to mean the same gNB),
> is now < 1 ms.
> Isn't that a good improvement?

Well, I doubt the radio has any service intelligence. It's just a
conduit. Depending on why two devices on the same radio have to
communicate, a cleverer system deep in the core would need to process
that before handing it back to the radio network.

Of course, it makes the case for deploying services at each base station
to localize services, but that could get expensive for an entire radio
network, particularly within a 100km Metro where fibre latency will
remain at ±1ms anyway.

Not to mention that with the exception of things like cars in a traffic
jam or on the same piece of highway, the chances of two devices talking
to each other over the same radio can't always be guaranteed.


>  
> I understand that this is a key enabler for driverless cars
> (real-time, automated vehicle navigation) - the V2I part of V2X.

I look forward to seeing this.

 
> Here's one blogger who agrees with you
> 
>  
> (@19:46) about coverage - and count me in.
> But, I guess, it's fair to say that this is the chicken-and-egg
> conundrum :)

The video won't play. Could be my browser.

Anyway, time will tell. I see 5G roll-out density like rolling out fibre
in places only where the postal service can get to. But I hope I'm wrong.

Mark.

Re: Has virtualization become obsolete in 5G?

[Mark Tinka]

On 5/Aug/20 18:39, Etienne-Victor Depasquale wrote:

>
> Umm, I don't think so.
> At least that's not the impression I got from the CNCF, Intel and Red Hat.
> They seem to be striving for K8s without the use of VM hypervisors.

Much to learn :-).

Mark.

Re: Has virtualization become obsolete in 5G?

[Mark Tinka]

On 4/Aug/20 18:05, adamv0...@netconsultings.com wrote:

> Yes that's exactly it. 
> Instead of a VDOM (or whatever is your FW vendor slicing mechanism) give each 
> customer a FW "instance" (VM/Containerized -if there's such a thing already) 
> and instantiate it on demand and with resources customer requested and 
> enforce utility billing. 
> Rinse and repeat for any other NF customer might need on your telco cloud 
> (fancy name for a data-canter full of compute)
> As simple as that -problem is that all vendors haven't quite gotten up to 
> speed with licensing models, we need an overall Gbps throughput pool licenses 
> not per VM/Container Gbps pool. 

We attempted this for a vCPE model based on CSR1000v.

The options were to either give each customer their own VM, or share a
single VM across all customers. The former was too resource intensive,
while the latter suffered from an appropriate license billing model with
Cisco.

For me, vCPE's make plenty of sense because you can automatically impose
IPv6 on all customers without them being bothered about what it is.

Mark.

Re: RPKI TAs

[Nathalie Trenaman]

Hi Randy, all,

We’ve updated our page: 
https://www.ripe.net/manage-ips-and-asns/resource-management/certification/ripe-ncc-rpki-trust-anchor-structure
 

It now shows the correct TALs:
https://tal.rpki.ripe.net/ripe-ncc.tal  
(preferred)
https://tal.rpki.ripe.net/ripe-ncc-rfc8630.tal 
 
https://tal.rpki.ripe.net/ripe-ncc-validator-3.tal 
 (RIPE NCC RPKI Validator 3 
format)

I hope this helps. 

Best regards,
Nathalie Trenaman
RIPE NCC


> Op 2 aug. 2020, om 20:52 heeft Randy Bush  het volgende 
> geschreven:
> 
> so i was trying to ensure i had a current set of TALs and was directed to
> 
>
> https://www.ripe.net/manage-ips-and-asns/resource-management/certification/ripe-ncc-rpki-trust-anchor-structure
> 
> the supposed TAL at the bottom of the page is pretty creative.  anyone
> know what to do there?
> 
> i kinda hacked with emacs and get
> 
>rsync://rpki.ripe.net/ta/ripe-ncc-ta.cerpublic.key.info
> 
>
> MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0URYSGqUz2myBsOzeW1jQ6NsxNvlLMyhWknvnl8NiBCs/T/S2XuNKQNZ+wBZxIgPPV2pFBFeQAvoH/WK83HwA26V2siwm/MY2nKZ+Olw+wlpzlZ1p3Ipj2eNcKrmit8BwBC8xImzuCGaV0jkRB0GZ0hoH6Ml03umLprRsn6v0xOP0+l6Qc1ZHMFVFb385IQ7FQQTcVIxrdeMsoyJq9eMkE6DoclHhF/NlSllXubASQ9KUWqJ0+Ot3QCXr4LXECMfkpkVR2TZT+v5v658bHVs6ZxRD1b6Uk1uQKAyHUbn/tXvP8lrjAibGzVsXDT2L0x4Edx+QdixPgOji3gBMyL2VwIDAQAB
> 
> but kinda expected an rrdp uri too
> 
> and, to add insult to injury, the APNIC web page with their TAL
> 
>https://www.apnic.net/community/security/resource-certification/
> 
> requires javascript!
> 
> not to mention the ARIN stupidity
> 
> as if we needed another exercise in bureaucrats making operations
> painful.  most operations of any size have internal departments
> perfectly capable of doing that.
> 
> randy

Re: RPKI TAs

[Randy Bush]

> https://tal.rpki.ripe.net/ripe-ncc.tal (preferred)

looks great visually.  stuffed in a dragon validator, just for qa.

thanks!

randy

Re: Has virtualization become obsolete in 5G?

[Shane Ronan]

Yes they are for 5G core.

On Wed, Aug 5, 2020, 11:28 AM Mark Tinka  wrote:

>
>
> On 5/Aug/20 17:07, Shane Ronan wrote:
>
> > I think you'd be surprised how much of the 5G Core is containerized
> > for both the data and control planes in the next generations providers
> > are currently deploying.
>
> It's what I expect for new entrants that don't want to deal with
> traditional vendors.
>
> I'd be curious to see if legacy operators are shifting traffic away from
> iron to servers, and at what rate.
>
> Mark.
>

Re: BGP full feed for testing purposes

[Greg Sowell]

Sorry, it wasn't a bug; we had power issues at our DC a few days ago and
everything didn't come back up clean *sigh*.  Please test again when you
have a moment.

Thanks,
Greg

On Wed, Aug 5, 2020 at 4:15 PM Blažej Krajňák  wrote:

> Hi Lukasz,
>
> your feed is working well. Feed from Poland to me to Slovakia is better
> than expected :) It's my first live BGP full feed ever so I really
> appreciate you.
> Will this instance run for a longer time?
>
> btw:
> - converting RIS data via mrt2exabgp looks to be broken, it's falling on
> syntax error in source data. With routeviews.org data it's working but
> exabgp is single-thread (convergence takes some time) and use much more
> RAM to start with full feed config than I excepcted.
> - from gregsowell.com I received email with access credentials, however
> L2TP tunnel establishment is falling due to authentication error - looks
> like bug
>
>
> Thanks to everyone
> Blažej
>
> Dňa 2020-08-05 20:04 Łukasz Bromirski napísal(a):
> > Ah, one more thing:
> >
> >> On 5 Aug 2020, at 20:01, Łukasz Bromirski 
> >> wrote:
> >>
> >>
> >> …or you can do next best thing. Which is use AS 65001 and connect your
> >> router to AS 65000 under 94.246.173.181.
> >>
> >> Please note that’s just test instance, and it has conservative timers
> >> (3600/7200) to not overtax CPU.
> >>
> >> It’s test instance of CSR 1000v running 16.9.5.
> >>
> >> If there’ll be interest, I can setup similar box with IOS-XR and/or
> >> with IPv6.
> >
> > This is European feed from Poland, so YMMV, but it has 816,090
> > prefixes as we speak.
> >
> > Don’t kill me if it kills your router ;)
> >
> > —
> > ./
>


-- 

GregSowell.com
TheBrothersWISP.com
StrayaNet.com

Re: Has virtualization become obsolete in 5G?

[Mark Tinka]

On 6/Aug/20 15:43, Shane Ronan wrote:

> Yes they are for 5G core.

Right, but for legacy operators, or new entrants?

If you know where we can find some info about deployment and
experiences, that would be very interesting to read.

We've all been struggling to make Intel CPU's shift 10's, 40's and 100's
of Gbps of revenue traffic as a routing platform, so would like to know
how the operators are getting on with this.

Mark.

Re: Has virtualization become obsolete in 5G?

[Mel Beckman]

Mark,

I don’t think you’re going to move those volumes with Intel X86 chips. For 
example, AT&T’s Open Compute Project whitebox architecture is based on Broadcom 
Jericho2 processors, with aggregate on-chip throughput of 9.6 Tbps, and which 
support 24 ports at 400 Gbps each. This is where AT&T’s 5G slicing is taking 
place.

https://about.att.com/story/2019/open_compute_project.html

Intel has developed nothing like this, and has had to resort to acquisition of 
multi-chip solutions to get these speeds (e.g. its purchase of Barefoot 
Networks Tofino2 IP).

The X86 architecture is too complex and carries too much non-network-related 
baggage to be a serious player in 5G slicing.

 -mel

On Aug 6, 2020, at 8:24 AM, Mark Tinka  wrote:



On 6/Aug/20 15:43, Shane Ronan wrote:

Yes they are for 5G core.

Right, but for legacy operators, or new entrants?

If you know where we can find some info about deployment and
experiences, that would be very interesting to read.

We've all been struggling to make Intel CPU's shift 10's, 40's and 100's
of Gbps of revenue traffic as a routing platform, so would like to know
how the operators are getting on with this.

Mark.

Re: Has virtualization become obsolete in 5G?

[Mark Tinka]

On 6/Aug/20 17:43, Mel Beckman wrote:

> I don’t think you’re going to move those volumes with Intel X86 chips.
> For example, AT&T’s Open Compute Project whitebox architecture is
> based on Broadcom Jericho2 processors, with aggregate on-chip
> throughput of 9.6 Tbps, and which support 24 ports at 400 Gbps each.
> This is where AT&T’s 5G slicing is taking place.

My point exactly.

If much of the cloud-native is happening on servers with Intel chips,
and part of the micro-services is to also provide data plane
functionality at that level, I don't see how it can scale for legacy
mobile operators. It might make sense for niche, start-up mobile
operators with little-to-no traffic serving some unique case, but not
the classics we have today.

Now, if they are writing their own bits of code on or for white boxes
based on Broadcom et al, not sure that falls in the realm of
"micro-services with Kubernetes". But I could be wrong.


> Intel has developed nothing like this, and has had to resort to
> acquisition of multi-chip solutions to get these speeds (e.g. its
> purchase of Barefoot Networks Tofino2 IP).
>
> The X86 architecture is too complex and carries too much
> non-network-related baggage to be a serious player in 5G slicing.

Which we, as network operators, can all agree on.

But the 5G folk seem to have other ideas, so I just want to see what is
actually truth, and what's noise.

Mark.

Re: Has virtualization become obsolete in 5G?

[Christopher Morrow]

On Thu, Aug 6, 2020 at 11:52 AM Mark Tinka  wrote:

> On 6/Aug/20 17:43, Mel Beckman wrote:
>
> > I don’t think you’re going to move those volumes with Intel X86 chips.
> > For example, AT&T’s Open Compute Project whitebox architecture is
> > based on Broadcom Jericho2 processors, with aggregate on-chip
> > throughput of 9.6 Tbps, and which support 24 ports at 400 Gbps each.
> > This is where AT&T’s 5G slicing is taking place.
>
> My point exactly.
>
> If much of the cloud-native is happening on servers with Intel chips,
> and part of the micro-services is to also provide data plane
> functionality at that level, I don't see how it can scale for legacy
> mobile operators. It might make sense for niche, start-up mobile
> operators with little-to-no traffic serving some unique case, but not
> the classics we have today.

Isn't this just, really:
  1) some network gear with SDN bits that live on the next-rack over
servers/kubes
  2) services (microservices!) that do the SDN functions AND NFV
functions AND billing
  (extending IMS to the edge etc)

> Now, if they are writing their own bits of code on or for white boxes
> based on Broadcom et al, not sure that falls in the realm of
> "micro-services with Kubernetes". But I could be wrong.

the discussion (I think) got conflated here...
there's: "network equipment" and "microservices equipment" (service equipment?)

and really 'I need a fast, cheap network device I can dynamically program for
 things which don't really smell like 'DFZ size LPM routing"'

is just code for: "sdn control the switch, sending traffic either at
'default' or based
on 'service data' some microservice architecture of NFV things.

> > Intel has developed nothing like this, and has had to resort to
> > acquisition of multi-chip solutions to get these speeds (e.g. its
> > purchase of Barefoot Networks Tofino2 IP).
> >
> > The X86 architecture is too complex and carries too much
> > non-network-related baggage to be a serious player in 5G slicing.
>
> Which we, as network operators, can all agree on.
>
> But the 5G folk seem to have other ideas, so I just want to see what is
> actually truth, and what's noise.

5g folk seem to have lots of good marketing, and reasons to sell complexity
to their carrier 'partners' (captive prisoners? maybe that's too pejorative :) )

ISPs are hit hardest by COVID-19 disruption

[Hank Nussbacher]

  
  
https://betanews.com/2020/08/04/isps-covid-19-disruption/


Really?


-Hank


Caveat: The views expressed above are solely my own and do not
  express the views or opinions of my employer 

  

Re: ISPs are hit hardest by COVID-19 disruption

[J. Hellenthal via NANOG]

Just more hype looking to boost marketing

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Aug 6, 2020, at 21:23, Hank Nussbacher  wrote:
> 

Re: ISPs are hit hardest by COVID-19 disruption

[surfer]

On 8/6/20 4:20 PM, Hank Nussbacher wrote:


https://betanews.com/2020/08/04/isps-covid-19-disruption/


Really?

-




Not that I have seen.  Ours held up just fine.  No more and no less than 
normal stuff.  We had to do the 'traffic shuffle' (a new dance move; no 
really! :) but that's it.  They quote numbers like they know every 
outage on every ISP's network, though.



scott

Re: ISPs are hit hardest by COVID-19 disruption

[Mark Tinka]

On 7/Aug/20 04:20, Hank Nussbacher wrote:

> https://betanews.com/2020/08/04/isps-covid-19-disruption/
>
>
> Really?
>

If there's anyone I dislike more than opportunistic sales people that
lurk on NOG mailing lists, it's "consultants" who "research" the
"telecoms landscape" so they can give you a "5-year strategy document"
on where your business needs to go, that you will be asked pay good
money for... money that could have gone to actual problems.

Mark.

Re: ISPs are hit hardest by COVID-19 disruption

[Mark Tinka]

On 7/Aug/20 04:30, J. Hellenthal via NANOG wrote:

> Just more hype looking to boost marketing

You can't blame anyone for trying to make a buck in these Coronavirus
times. I've always said that if "research companies" that make their
money writing "strategy reports" that cost tens and hundreds of
thousands, if not millions of $$ for the poor victims that fall for them
really knew where all the profit was going to come from, they wouldn't
be sharing those ideas. They'd be out there executing on those
strategies themselves.

Mark.

Re: ISPs are hit hardest by COVID-19 disruption

[Mark Tinka]

On 7/Aug/20 04:46, surfer wrote:

> Not that I have seen.  Ours held up just fine.  No more and no less
> than normal stuff.  We had to do the 'traffic shuffle' (a new dance
> move; no really! :) but that's it.  They quote numbers like they know
> every outage on every ISP's network, though.
>

Despite the telecoms industry being what it is nowadays, I'd say most
ISP's, globally, have actually benefited from people needing to use the
infrastructure more than ever.

Even for operators that may have lost some customers, revenues were
actually up.

Telecoms research consultants are paid to write reports. There is no
actual requirement for them to know what we really do.

Mark.

Re: Has virtualization become obsolete in 5G?

[Mark Tinka]

On 6/Aug/20 21:05, Christopher Morrow wrote:

> Isn't this just, really:
>   1) some network gear with SDN bits that live on the next-rack over
> servers/kubes
>   2) services (microservices!) that do the SDN functions AND NFV
> functions AND billing
>   (extending IMS to the edge etc)

I can already see how we are going to spend the next 10 years defining
this :-)...


> the discussion (I think) got conflated here...
> there's: "network equipment" and "microservices equipment" (service 
> equipment?)
>
> and really 'I need a fast, cheap network device I can dynamically program for
>  things which don't really smell like 'DFZ size LPM routing"'
>
> is just code for: "sdn control the switch, sending traffic either at
> 'default' or based
> on 'service data' some microservice architecture of NFV things.

I think we've just given vendors job security for another decade, hehe.


> 5g folk seem to have lots of good marketing, and reasons to sell complexity
> to their carrier 'partners' (captive prisoners? maybe that's too pejorative 
> :) )

Amen!

Mark.