Re: Has virtualization become obsolete in 5G?

[Etienne-Victor Depasquale]

I'm sorry, I didn't realize that anyone would get ruffled.

On Sat, Aug 1, 2020 at 11:38 PM Scott Weeks  wrote:

>
>
> --- ed...@ieee.org wrote:
> From: Etienne-Victor Depasquale 
>
> See, for example, Azhar Sayeed's (Red Hat) contribution here
> @15:33.
> 
>
>
> Don't send links to this list that require one to register
> to read the article and then say, "By registering for our
> site, your email will be added to our promotions list" and
> "Occasionally our trusted partners may want to send you
> information about exciting new products and services"
>
> No one's going to click on that!
>
> scott
>


-- 
Ing. Etienne-Victor Depasquale
Assistant Lecturer
Department of Communications & Computer Engineering
Faculty of Information & Communication Technology
University of Malta
Web. https://www.um.edu.mt/profile/etiennedepasquale

Re: Issue with Noction IRP default setting (Was: BGP route hijack by AS10990)

[Robert Raszuk]

All,

Watching this thread with interest got an idea - let me run it by this list
before taking it any further (ie. to IETF).

How about we learn from this and try to make BGP just a little bit safer ?

*Idea: *

In all stub (non transit) ASNs we modify BGP spec and disable automatic
iBGP to eBGP advertisement ?

*Implementation: *

Vendors to allow to define as part of global bgp configuration if given ASN
is transit or not. The default is to be discussed - no bias.

*Benefit: *

Without any issues anyone playing any tools in his network will be able to
just issue one cli and be protected from accidentally hurting others. Yet
naturally he will still be able to advertise his neworks just as today
except by explicit policy in any shape and form we would find proper
(example: "redistribute iBGP to eBGP policy-X").

We could even discuss if this should be perhaps part of BGP OPEN or BGP
capabilities too such that two sides of eBGP session must agree with each
other before bringing eBGP up.

Comments, questions, flames - all welcome :)

Cheers,
Robert.

PS. Such a definition sure can and likely will be misused (especially if we
would just settle on only a single side setting it - but that will not
cause any more harm as not having it at all.

Moreover I can already see few other good options which BGP implementation
or BGP spec can be augmented with once we know we are stub or for that
matter once it knows it is transit 

Re: Issue with Noction IRP default setting (Was: BGP route hijack by AS10990)

[Mark Tinka]

On 1/Aug/20 18:58, Job Snijders wrote:

> Following a large scale BGP incident in March 2015, noction made it
> possible to optionally set the well-known NO_EXPORT community on route
> advertisements originated by IRP instances.
>
> "In order to further reduce the likelihood of these problems
> occurring in the future, we will be adding a feature within Noction
> IRP to give an option to tag all the more specific prefixes that it
> generates with the BGP NO_EXPORT community. This will not be enabled
> by default [snip]"
> https://www.noction.com/blog/route-optimizers
> Mar 27, 2015
>
> Due to NO_EXPORT not being set in the default configuration, there are
> probably if not certainly many unsuspecting network engineers who end up
> deploying this software - without ever even considering - to change that
> one setting in the configuration.
>
> Fast forward a few years and a few incidents, on the topic of default
> settings, following the Cloudflare/DQE/Verizon incident:
>
> "We do have no export community support and have done for many
> years. The use of more specifics is also optional. Neither replaces
> the need for filters."
> https://twitter.com/noction/status/1143177562191011840
> Jun 24, 2019
>
> Community members responded:
>
> "Noction have been facilitating Internet outages for years and
> years and the best thing they can say in response is that it is
> technically possible to use their product responsibly, they just
> don't ship it that way."
> https://twitter.com/PowerDNS_Bert/status/1143252745257979905
> June 24, 2019
>
> Last year Noction stated:
>
> "Nobody found this leak pleasant."
> https://www.noction.com/news/incident-response
> June 26, 2019
>
> Sentiment we all can agree with, change is needed!
>
> As far as I know, Noction IRP is the ONLY commercially available
> off-the-shelf BGP route manipulation software which - as default - does
> NOT set the BGP well-known NO_EXPORT community on the product's route
> advertisements. This is a product design decision which causes
> collateral damage.
>
> I would like to urge Noction to reconsider their position. Seek to
> migrate the existing users to use NO_EXPORT, and release a new version
> of the IRP software which sets NO_EXPORT BY DEFAULT on all generated
> routes.

A great first step!

Mark.

Re: Issue with Noction IRP default setting (Was: BGP route hijack by AS10990)

[Mark Tinka]

On 1/Aug/20 22:29, Ryan Hamel wrote:
> Job,
>
> I disagree on the fact that it is not fair to the BGP implementation
> ecosystem, to enforce a single piece of software to activate the
> no-export community by default, due to ignorance from the engineer(s)
> implementing the solution. It should be common sense that certain
> routes that should be advertised beyond the local AS, just like
> RFC1918 routes, and more. Also, wasn't it you that said Cisco routers
> had a bug in ignoring NO_EXPORT? Would you go on a rant with Cisco,
> even if Noction add that enabled checkbox by default?
>
> Why are you not on your soap box about BIRD, FRrouting, OpenBGPd,
> Cisco, Juniper, etc... about how they can possibly allow every day
> screw ups to happen, but the same options like the NO_EXPORT community
> are available for the engineer to use? One solution would be to
> implement "BGP Group/Session Profiles" (ISP/RTBH/DDOS Filtering/Route
> Optimizers/etc) or a "BGP Session Wizard" (ask the operator questions
> about their intentions), then automatically generate import and export
> policies based on known accepted practices.
>
> Another solution could be having the BGP daemon disclose the make,
> model family, and exact model of hardware it is running on, to BGP
> peers, and add more knobs into policy creation to match said values,
> and take action appropriately. That would be useful in getting around
> vendor specific issues, as well as belt & suspenders protection.

Most (if not all) people buying BGP optimizers aren't using them for
regular BGP-speaking routers to the rest of the Internet or their core
network.

BGP optimizers serve a unique use-case, which works in the way it does
to create an expected risk as we saw in this and past incidents. On that
basis, I think Job's request to make NO_EXPORT a mandatory default (I'd
go further to say the new default mode can be user-disabled, but with an
unmistakable warning in the UI) is not unreasonable.

Mark.

Re: Has virtualization become obsolete in 5G?

[Mark Tinka]

On 1/Aug/20 23:53, John Lee wrote:

>
> In 2000 we put our first pre-standard cloud together with multi
> Gigabit routers and Sun workstations at 45 PoPs in the US, 3 in Asia
> and 6 in Europe and implemented a "cloud" O/S. Our fastest links were
> 10 Gbps. Now we can have 2-50 Tbps per fiber using Superchannel DWDM
> technology between PoP, data centers or cell towers. Network control
> functions can dynamically change by using Dynamic Reprogrammable
> EPROMs from companies like Xilinx and Intel to repurpose firmware
> control and device functions.

I believe that if a system has a single (and often simple) function, as
in the case of DWDM, you can have an off-site control plane to decide
what the network should transport.

The problem with IP networks is that you get multiple services that they
need to carry at various layers of the stack, that it becomes tricky not
to have some kind of localized control plane to ensure the right
intelligence is onboard to advise the data plane about what to do, in a
changing network environment.

While we can do this with a VM on a server, the server's NIC lets us
down when we need to push 100's of Gbps or 10's of Tbps.


> Certain 5G proposals are discussing network slicing et al to
> virtualize control functions that can work better without
> virtualization. Current 5G protocol submissions that I have reviewed
> are way too complex to work out in the real world on real networks,
> maintained by union labor. (This is not a dig at union labor, as they
> are some of the best trained techs.) :)

In a world where user traffic is exceedingly moving away from private
networks and on to the the public Internet, I struggle to understand how
5G's "network slicing" is going to deliver what it promises, when the
network is merely seen as a means to get users to what they want. In
most cases, what they want will not be hosted locally within the mobile
network, making discrete SLR's as prescribed by network slicing,
somewhat useless.

With all the bells & whistles 5G is claiming will change the world, I
just don't see how that will work as more services move into
over-the-top public clouds.

Mark.

Re: Has virtualization become obsolete in 5G?

[Mike Hammett]

There's always someone ruffled about something. Don't give it a second thought. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Etienne-Victor Depasquale"  
To: sur...@mauigateway.com 
Cc: "NANOG"  
Sent: Sunday, August 2, 2020 2:42:11 AM 
Subject: Re: Has virtualization become obsolete in 5G? 


I'm sorry, I didn't realize that anyone would get ruffled. 


On Sat, Aug 1, 2020 at 11:38 PM Scott Weeks < sur...@mauigateway.com > wrote: 




--- ed...@ieee.org wrote: 
From: Etienne-Victor Depasquale < ed...@ieee.org > 

See, for example, Azhar Sayeed's (Red Hat) contribution here 
< https://www.lightreading.com/webinar.asp?webinar_id=1608 >@15:33. 
 


Don't send links to this list that require one to register 
to read the article and then say, "By registering for our 
site, your email will be added to our promotions list" and 
"Occasionally our trusted partners may want to send you 
information about exciting new products and services" 

No one's going to click on that! 

scott 





-- 


Ing. Etienne-Victor Depasquale 
Assistant Lecturer 
Department of Communications & Computer Engineering 
Faculty of Information & Communication Technology 
University of Malta 
Web. https://www.um.edu.mt/profile/etiennedepasquale 

Re: Issue with Noction IRP default setting (Was: BGP route hijack by AS10990)

[Ca By]

On Sun, Aug 2, 2020 at 4:34 AM Robert Raszuk  wrote:

> All,
>
> Watching this thread with interest got an idea - let me run it by this
> list before taking it any further (ie. to IETF).
>
> How about we learn from this and try to make BGP just a little bit safer ?
>
> *Idea: *
>
> In all stub (non transit) ASNs we modify BGP spec and disable automatic
> iBGP to eBGP advertisement ?
>

Why do you believe a stub AS was involved or that would have changed this
situation?

The whole point of Noction is for a bad isp to fake more specific routes to
downstream customers.  Noction is sold to ISPs, aka transit AS, afaik



> *Implementation: *
>
> Vendors to allow to define as part of global bgp configuration if
> given ASN is transit or not. The default is to be discussed - no bias.
>

Oh. A configuration knob. Noction had knobs, the world runs of 5 year old
software with default configs.


> *Benefit: *
>
> Without any issues anyone playing any tools in his network will be able to
> just issue one cli
>

Thanks for no pretending we configure our networks with yang model apis

and be protected from accidentally hurting others. Yet naturally he will
> still be able to advertise his neworks just as today except by explicit
> policy in any shape and form we would find proper (example:
> "redistribute iBGP to eBGP policy-X").
>

XR rolls this way today, thanks Cisco. But the “any” keyword exists, so
yolo.


> We could even discuss if this should be perhaps part of BGP OPEN or BGP
> capabilities too such that two sides of eBGP session must agree with each
> other before bringing eBGP up.
>
> Comments, questions, flames - all welcome :)
>
> Cheers,
> Robert.
>
> PS. Such a definition sure can and likely will be misused (especially if
> we would just settle on only a single side setting it - but that will not
> cause any more harm as not having it at all.
>
> Moreover I can already see few other good options which BGP implementation
> or BGP spec can be augmented with once we know we are stub or for that
> matter once it knows it is transit 
>
>

Re: Issue with Noction IRP default setting (Was: BGP route hijack by AS10990)

[Robert Raszuk]

Hi Ca,

> Noction is sold to ISPs, aka transit AS, afaik

Interesting.

My impression always was by talking to Noction some time back that mainly
what they do is a flavor of performance routing.  But this is not about
Noction IMHO.

If I am a non transit ASN with N upstream ISPs I want to exit not in a hot
potato style ... if I care about my services I want to exit the best
performing way to reach back customers. That's btw what Cisco PFR does or
Google's Espresso or Facebook Edge Fabric etc ...

And you have few vendors offering this as well as bunch of home grown tools
attempting to do the same. Go and mandate that all of them will do
NO-EXPORT if they insert any routes ... And we will see more and more of
those type of tools coming.

Sure we have implementations with obligatory policy on eBGP - cool. And yes
we have match "ANY" too.

So if your feedback is that to limit the iBGP routes to go out over eBGP
this is all sufficient and we do not need a bit more protection there then
case solved.

Cheers,
R.



On Sun, Aug 2, 2020 at 4:42 PM Ca By  wrote:

>
>
> On Sun, Aug 2, 2020 at 4:34 AM Robert Raszuk  wrote:
>
>> All,
>>
>> Watching this thread with interest got an idea - let me run it by this
>> list before taking it any further (ie. to IETF).
>>
>> How about we learn from this and try to make BGP just a little bit safer
>> ?
>>
>> *Idea: *
>>
>> In all stub (non transit) ASNs we modify BGP spec and disable automatic
>> iBGP to eBGP advertisement ?
>>
>
> Why do you believe a stub AS was involved or that would have changed this
> situation?
>
> The whole point of Noction is for a bad isp to fake more specific routes
> to downstream customers.  Noction is sold to ISPs, aka transit AS, afaik
>
>
>
>> *Implementation: *
>>
>> Vendors to allow to define as part of global bgp configuration if
>> given ASN is transit or not. The default is to be discussed - no bias.
>>
>
> Oh. A configuration knob. Noction had knobs, the world runs of 5 year old
> software with default configs.
>
>
>> *Benefit: *
>>
>> Without any issues anyone playing any tools in his network will be able
>> to just issue one cli
>>
>
> Thanks for no pretending we configure our networks with yang model apis
>
> and be protected from accidentally hurting others. Yet naturally he will
>> still be able to advertise his neworks just as today except by explicit
>> policy in any shape and form we would find proper (example:
>> "redistribute iBGP to eBGP policy-X").
>>
>
> XR rolls this way today, thanks Cisco. But the “any” keyword exists, so
> yolo.
>
>
>> We could even discuss if this should be perhaps part of BGP OPEN or BGP
>> capabilities too such that two sides of eBGP session must agree with each
>> other before bringing eBGP up.
>>
>> Comments, questions, flames - all welcome :)
>>
>> Cheers,
>> Robert.
>>
>> PS. Such a definition sure can and likely will be misused (especially if
>> we would just settle on only a single side setting it - but that will not
>> cause any more harm as not having it at all.
>>
>> Moreover I can already see few other good options which BGP
>> implementation or BGP spec can be augmented with once we know we are stub
>> or for that matter once it knows it is transit 
>>
>>

Re: Issue with Noction IRP default setting (Was: BGP route hijack by AS10990)

[Mark Tinka]

On 2/Aug/20 01:44, Ryan Hamel wrote:
> Matt,
>
> Why are you blaming the ease of use on the vendor, for the operators
> lack of knowledge regarding BGP? That is like blaming a vehicle
> manufacturer for a person pressing the gas pedal in a car and not
> giving a toss about the rules of the road. The base foundation
> regarding the rules of the road mostly apply the same for driving a
> car, truck, bus, and semi/lorry truck. There is no excuse for
> ignorance just because the user interface is different (web browser
> vs. SSH client).

Actually, there is.

One has to actually acquire knowledge about not only driving a car, but
driving it in public. That knowledge is then validated by a
gubbermint-sanctioned driver's license test. If you fail, you aren't
allowed to drive. If you are caught driving without a driver's license,
you pay the penalty.

There is no requirement for a license in order to run power into a
router and hook it up to the Internet. This is the problem I have with
the current state of how we support BGP actors.

> Adding a take on this, there are kids born after 9/11, with IP
> allocations and ASNs experimenting in the DFZ right now. If they can
> make it work, and not cause harm to other members in this community,
> it clearly demonstrates a lack of knowledge, or honest human error
> (which will never go away).

We should not be celebrating this.


>
> Anything that can be used, can be misused. With that said, why
> shouldn't ALL BGP software implementations encourage best practice?
> They decided RPKI validation was a good thing.

The larger question is we should find a way to make our industry
genuinely qualification-based, and not "free for all that decides they
want to try it out".

I don't yet know how to do that, but we certainly need to start thinking
more seriously about it. Kids born after 9/11 successfully experimenting
on a global network is not where the bar ought to be.

Mark.

Re: Issue with Noction IRP default setting (Was: BGP route hijack by AS10990)

[nanog]

And bgp "optimizer" won't do that
At best, they will let you get the less worst



On 8/2/20 6:36 PM, Robert Raszuk wrote:

if I care about my services I want to exit the best
performing way to reach back customers.

Re: BGP route hijack by AS10990

[Darrell Budic]

On Jul 30, 2020, at 5:37 PM, Baldur Norddahl  wrote:
> 
> Telia implements RPKI filtering so the question is did it work? Were any 
> affected prefixes RPKI signed? Would any prefixes have avoided being hijacked 
> if RPKI signing had been in place?
> 
> Regards 
> 
> Baldur - who had to turn off RPKI filtering at the request of JTAC to stop 
> our mx204s from crashing :-(
> 

Oh uh, I’m getting close to getting RPKI going on my mx204s, or was until you 
posted that. What’s the story there, and perhaps which junos version?

RPKI TAs

[Randy Bush]

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]

> 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

btw this is not correct/useful anyway.  it probably should be more like

rsync://rpki.ripe.net/ta/ripe-ncc-ta.cer


MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0URYSGqUz2myBsOzeW1jQ6NsxNvlLMyhWknvnl8NiBCs/T/S2XuNKQNZ+wBZxIgPPV2pFBFeQAvoH/WK83HwA26V2siwm/MY2nKZ+Olw+wlpzlZ1p3Ipj2eNcKrmit8BwBC8xImzuCGaV0jkRB0GZ0hoH6Ml03umLprRsn6v0xOP0+l6Qc1ZHMFVFb385IQ7FQQTcVIxrdeMsoyJq9eMkE6DoclHhF/NlSllXubASQ9KUWqJ0+Ot3QCXr4LXECMfkpkVR2TZT+v5v658bHVs6ZxRD1b6Uk1uQKAyHUbn/tXvP8lrjAibGzVsXDT2L0x4Edx+QdixPgOji3gBMyL2VwIDAQAB

Re: Issue with Noction IRP default setting (Was: BGP route hijack by AS10990)

[Ross Tajvar]

Mark,

I think trying to implement some kind of license requirement for DFZ
participants is a step in the wrong direction and a waste of time and
money. How would you even enforce it? If the goal is just to provide a
bigger barrier to "kids born after 9/11", why not just increase RIR fees,
or add an age requirement for individuals? And anyway, why do we need to
increase that barrier? What problem does that actually solve? Are "kids
born after 9/11" the ones propagating route leaks? I don't think they are.
But the reason for that is not that they're necessarily more skilled
operators than "adults born before 9/11" or anyone else - it's that they
are being filtered appropriately by the likes of Vultr, etc. Verizon (and
other large incumbents) could learn something from them.

Let's try to stay away from exclusivity for exclusivity's sake and actually
focus on solving the real problems we have.

On Sun, Aug 2, 2020 at 12:45 PM Mark Tinka  wrote:

>
>
> On 2/Aug/20 01:44, Ryan Hamel wrote:
>
> Matt,
>
> Why are you blaming the ease of use on the vendor, for the operators lack
> of knowledge regarding BGP? That is like blaming a vehicle manufacturer for
> a person pressing the gas pedal in a car and not giving a toss about the
> rules of the road. The base foundation regarding the rules of the road
> mostly apply the same for driving a car, truck, bus, and semi/lorry truck.
> There is no excuse for ignorance just because the user interface is
> different (web browser vs. SSH client).
>
>
> Actually, there is.
>
> One has to actually acquire knowledge about not only driving a car, but
> driving it in public. That knowledge is then validated by a
> gubbermint-sanctioned driver's license test. If you fail, you aren't
> allowed to drive. If you are caught driving without a driver's license, you
> pay the penalty.
>
> There is no requirement for a license in order to run power into a router
> and hook it up to the Internet. This is the problem I have with the current
> state of how we support BGP actors.
>
> Adding a take on this, there are kids born after 9/11, with IP allocations
> and ASNs experimenting in the DFZ right now. If they can make it work, and
> not cause harm to other members in this community, it clearly demonstrates
> a lack of knowledge, or honest human error (which will never go away).
>
>
> We should not be celebrating this.
>
>
>
> Anything that can be used, can be misused. With that said, why shouldn't
> ALL BGP software implementations encourage best practice? They decided RPKI
> validation was a good thing.
>
>
> The larger question is we should find a way to make our industry genuinely
> qualification-based, and not "free for all that decides they want to try it
> out".
>
> I don't yet know how to do that, but we certainly need to start thinking
> more seriously about it. Kids born after 9/11 successfully experimenting on
> a global network is not where the bar ought to be.
>
> Mark.
>

Re: Issue with Noction IRP default setting (Was: BGP route hijack by AS10990)

[Ca By]

On Sun, Aug 2, 2020 at 9:36 AM Robert Raszuk  wrote:

> Hi Ca,
>
> > Noction is sold to ISPs, aka transit AS, afaik
>
> Interesting.
>
> My impression always was by talking to Noction some time back that mainly
> what they do is a flavor of performance routing.  But this is not about
> Noction IMHO.
>
> If I am a non transit ASN with N upstream ISPs I want to exit not in a hot
> potato style ... if I care about my services I want to exit the best
> performing way to reach back customers. That's btw what Cisco PFR does or
> Google's Espresso or Facebook Edge Fabric etc ...
>
> And you have few vendors offering this as well as bunch of home grown
> tools attempting to do the same. Go and mandate that all of them will do
> NO-EXPORT if they insert any routes ... And we will see more and more of
> those type of tools coming.
>
> Sure we have implementations with obligatory policy on eBGP - cool. And
> yes we have match "ANY" too.
>
> So if your feedback is that to limit the iBGP routes to go out over eBGP
> this is all sufficient and we do not need a bit more protection there then
> case solved.
>
> Cheers,
> R.
>
>
My feedback is the local_pref is complete for this behavior of setting an
outbound, including being non-transitive

FB uses local-pref for this afaik
https://research.fb.com/blog/2017/08/steering-oceans-of-content-to-the-world/


>
> On Sun, Aug 2, 2020 at 4:42 PM Ca By  wrote:
>
>>
>>
>> On Sun, Aug 2, 2020 at 4:34 AM Robert Raszuk  wrote:
>>
>>> All,
>>>
>>> Watching this thread with interest got an idea - let me run it by this
>>> list before taking it any further (ie. to IETF).
>>>
>>> How about we learn from this and try to make BGP just a little bit safer
>>> ?
>>>
>>> *Idea: *
>>>
>>> In all stub (non transit) ASNs we modify BGP spec and disable automatic
>>> iBGP to eBGP advertisement ?
>>>
>>
>> Why do you believe a stub AS was involved or that would have changed this
>> situation?
>>
>> The whole point of Noction is for a bad isp to fake more specific routes
>> to downstream customers.  Noction is sold to ISPs, aka transit AS, afaik
>>
>>
>>
>>> *Implementation: *
>>>
>>> Vendors to allow to define as part of global bgp configuration if
>>> given ASN is transit or not. The default is to be discussed - no bias.
>>>
>>
>> Oh. A configuration knob. Noction had knobs, the world runs of 5 year old
>> software with default configs.
>>
>>
>>> *Benefit: *
>>>
>>> Without any issues anyone playing any tools in his network will be able
>>> to just issue one cli
>>>
>>
>> Thanks for no pretending we configure our networks with yang model apis
>>
>> and be protected from accidentally hurting others. Yet naturally he will
>>> still be able to advertise his neworks just as today except by explicit
>>> policy in any shape and form we would find proper (example:
>>> "redistribute iBGP to eBGP policy-X").
>>>
>>
>> XR rolls this way today, thanks Cisco. But the “any” keyword exists, so
>> yolo.
>>
>>
>>> We could even discuss if this should be perhaps part of BGP OPEN or BGP
>>> capabilities too such that two sides of eBGP session must agree with each
>>> other before bringing eBGP up.
>>>
>>> Comments, questions, flames - all welcome :)
>>>
>>> Cheers,
>>> Robert.
>>>
>>> PS. Such a definition sure can and likely will be misused (especially if
>>> we would just settle on only a single side setting it - but that will not
>>> cause any more harm as not having it at all.
>>>
>>> Moreover I can already see few other good options which BGP
>>> implementation or BGP spec can be augmented with once we know we are stub
>>> or for that matter once it knows it is transit 
>>>
>>>

Re: Issue with Noction IRP default setting (Was: BGP route hijack by AS10990)

[Mark Tinka]

On 2/Aug/20 21:37, Ross Tajvar wrote:
> Mark,
>
> I think trying to implement some kind of license requirement for DFZ
> participants is a step in the wrong direction and a waste of time and
> money. How would you even enforce it? If the goal is just to provide a
> bigger barrier to "kids born after 9/11", why not just increase RIR
> fees, or add an age requirement for individuals? And anyway, why do we
> need to increase that barrier? What problem does that actually solve?
> Are "kids born after 9/11" the ones propagating route leaks? I don't
> think they are. But the reason for that is not that they're
> necessarily more skilled operators than "adults born before 9/11" or
> anyone else - it's that they are being filtered appropriately by the
> likes of Vultr, etc. Verizon (and other large incumbents) could learn
> something from them.
>
> Let's try to stay away from exclusivity for exclusivity's sake and
> actually focus on solving the real problems we have.

Like I said before, "guidance" rather than "regulation".

The way the Internet has worked for 4+ decades has been what has made it
so successful. However, it's starting to catch up with us, so we need to
figure it out, and not bury our heads in the sand until it hurts me or
you more directly for either us to care.

Like I also said, I don't quite know how to solve this problem yet. What
I do know is if we keep having this dance every few months each year, it
will be 2050 and we'll still be in the same place, only worse.

Before we can find a solution, we have to realize that there is a
problem. There is enough smarts in the community to find a solution.
Hopefully before some silly gubbermint (TikTok ban, anyone?) decides for us.

Mark.

Re: Issue with Noction IRP default setting (Was: BGP route hijack by AS10990)

[Ross Tajvar]

I guess I missed your mention of "guidance rather than regulation", and am
still missing it, unless you're referring to another thread.

If you want to acknowledge a problem with internet governance and bring it
to this mailing list for discussion, that sounds like a good idea. But the
only "problem" I've seen you bring up in this thread is the participation
of young people, and I've yet to hear a reason why that's a bad thing. This
just sounds like gatekeeping to me.

If we want to improve routing security, then rather than making vague
claims about things "catching up with us" with no clear problem statement,
we should be focusing our efforts on basic safeguards like filtering and
RPKI OV. I don't consider that "burying my head in the sand".

On Sun, Aug 2, 2020, 5:24 PM Mark Tinka  wrote:

>
>
> On 2/Aug/20 21:37, Ross Tajvar wrote:
> > Mark,
> >
> > I think trying to implement some kind of license requirement for DFZ
> > participants is a step in the wrong direction and a waste of time and
> > money. How would you even enforce it? If the goal is just to provide a
> > bigger barrier to "kids born after 9/11", why not just increase RIR
> > fees, or add an age requirement for individuals? And anyway, why do we
> > need to increase that barrier? What problem does that actually solve?
> > Are "kids born after 9/11" the ones propagating route leaks? I don't
> > think they are. But the reason for that is not that they're
> > necessarily more skilled operators than "adults born before 9/11" or
> > anyone else - it's that they are being filtered appropriately by the
> > likes of Vultr, etc. Verizon (and other large incumbents) could learn
> > something from them.
> >
> > Let's try to stay away from exclusivity for exclusivity's sake and
> > actually focus on solving the real problems we have.
>
> Like I said before, "guidance" rather than "regulation".
>
> The way the Internet has worked for 4+ decades has been what has made it
> so successful. However, it's starting to catch up with us, so we need to
> figure it out, and not bury our heads in the sand until it hurts me or
> you more directly for either us to care.
>
> Like I also said, I don't quite know how to solve this problem yet. What
> I do know is if we keep having this dance every few months each year, it
> will be 2050 and we'll still be in the same place, only worse.
>
> Before we can find a solution, we have to realize that there is a
> problem. There is enough smarts in the community to find a solution.
> Hopefully before some silly gubbermint (TikTok ban, anyone?) decides for
> us.
>
> Mark.
>
>

Paging Comcast

[Aaron C. de Bruyn via NANOG]

I need to get in touch with someone at Comcast urgently.

We just acquired an office.  Their service is hosed up and their IPs are
routing out of Washington State to Ashburn VA before dying.  A tech is
on-site and says there's something wrong with the account and that it might
be because it's a "national account".

I asked him to just set me up with new service.  He said he can't and I
have to go through a sales rep or the support number.

My sales guy isn't answering and every time I wade through 5 minutes of IVR
and reach a human and explain it, they say "hang on a moment" and then I'm
transferred back to the IVR.

I desperately need to fix the issue with static IPs on the existing account
or get new service installed because we're supposed to be live Monday
morning at 7:30 AM local time.

-A

Re: Issue with Noction IRP default setting (Was: BGP route hijack by AS10990)

[Mike Hammett]

I don't think there's any requirement for it to be for downstream customers 
(from a BGP perspective) or any relatance to transit ASes. 




Web hosting companies, their AS, no client ASes, huge optimization going on. 
I'd think mostly because the major eyeball ISPs have garbage peering policies 
and like to run their ports hot to force you to buy their transit\DIA. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Ca By"  
To: "Robert Raszuk"  
Cc: nanog@nanog.org 
Sent: Sunday, August 2, 2020 9:42:12 AM 
Subject: Re: Issue with Noction IRP default setting (Was: BGP route hijack by 
AS10990) 







On Sun, Aug 2, 2020 at 4:34 AM Robert Raszuk < rob...@raszuk.net > wrote: 




All, 


Watching this thread with interest got an idea - let me run it by this list 
before taking it any further (ie. to IETF). 


How about we learn from this and try to make BGP just a little bit safer ? 


Idea: 


In all stub (non transit) ASNs we modify BGP spec and disable automatic iBGP to 
eBGP advertisement ? 





Why do you believe a stub AS was involved or that would have changed this 
situation? 


The whole point of Noction is for a bad isp to fake more specific routes to 
downstream customers. Noction is sold to ISPs, aka transit AS, afaik 









Implementation: 


Vendors to allow to define as part of global bgp configuration if given ASN is 
transit or not. The default is to be discussed - no bias. 




Oh. A configuration knob. Noction had knobs, the world runs of 5 year old 
software with default configs. 








Benefit: 


Without any issues anyone playing any tools in his network will be able to just 
issue one cli 




Thanks for no pretending we configure our networks with yang model apis 





and be protected from accidentally hurting others. Yet naturally he will still 
be able to advertise his neworks just as today except by explicit policy in any 
shape and form we would find proper (example: "redistribute iBGP to eBGP 
policy-X"). 





XR rolls this way today, thanks Cisco. But the “any” keyword exists, so yolo. 








We could even discuss if this should be perhaps part of BGP OPEN or BGP 
capabilities too such that two sides of eBGP session must agree with each other 
before bringing eBGP up. 



Comments, questions, flames - all welcome :) 



Cheers, 
Robert. 

PS. Such a definition sure can and likely will be misused (especially if we 
would just settle on only a single side setting it - but that will not cause 
any more harm as not having it at all. 


Moreover I can already see few other good options which BGP implementation or 
BGP spec can be augmented with once we know we are stub or for that matter once 
it knows it is transit  

Re: Paging Comcast

[Aaron C. de Bruyn via NANOG]

Someone reached out who could shove a new service order into the queue for
the tech and we'll deal with the old broken connection on Monday when the
Comcast premier group opens back up.

Thanks and sorry for the noise.

-A

On Sun, Aug 2, 2020 at 3:55 PM Aaron C. de Bruyn  wrote:

> I need to get in touch with someone at Comcast urgently.
>
> We just acquired an office.  Their service is hosed up and their IPs are
> routing out of Washington State to Ashburn VA before dying.  A tech is
> on-site and says there's something wrong with the account and that it might
> be because it's a "national account".
>
> I asked him to just set me up with new service.  He said he can't and I
> have to go through a sales rep or the support number.
>
> My sales guy isn't answering and every time I wade through 5 minutes of
> IVR and reach a human and explain it, they say "hang on a moment" and then
> I'm transferred back to the IVR.
>
> I desperately need to fix the issue with static IPs on the existing
> account or get new service installed because we're supposed to be live
> Monday morning at 7:30 AM local time.
>
> -A
>

Re: Issue with Noction IRP default setting (Was: BGP route hijack by AS10990)

[Mark Tinka]

On 3/Aug/20 00:03, Ross Tajvar wrote:
> I guess I missed your mention of "guidance rather than regulation",
> and am still missing it, unless you're referring to another thread.
>
> If you want to acknowledge a problem with internet governance and
> bring it to this mailing list for discussion, that sounds like a good
> idea. But the only "problem" I've seen you bring up in this thread is
> the participation of young people, and I've yet to hear a reason why
> that's a bad thing. This just sounds like gatekeeping to me.
>
> If we want to improve routing security, then rather than making vague
> claims about things "catching up with us" with no clear problem
> statement, we should be focusing our efforts on basic safeguards like
> filtering and RPKI OV. I don't consider that "burying my head in the
> sand".

You may have missed most of these fundamentals much earlier in the thread.

I'm not looking to repeat myself, so you're welcome to start from the
top and come back if you have any more questions.

Mark.

Re: Has virtualization become obsolete in 5G?

[Mark Tinka]

On 2/Aug/20 06:51, Ahmed elBorno wrote:
> Maybe I am off topic a little bit here and i'd like to be educated if
> i am wrong but I think those 5G applications will move from VMs into
> containers/microservices when their vendors see a business case to
> rearchitect them, maybe its already happening as we speak.

I'm still trying to figure out what "these 5G applications" are :-).


>
> On the other side of that coin is that product managers of these 5G
> apps seeing the margins on their apps diminish when they slice them to
> a form that allows other "orchestrators" to deploy them.

My understanding of "network slicing" is that an operator lets an MVNO
ride their network (happens today already), and that MVNO can further
"slice" their portion of the operators network to deliver different
performance levels for the different services they offer down to the
end-user.

Still not sure how this will work considering a great deal of the global
Internet is for services that live on the public Internet, and many
specialized/private services would typically still run over fibre. I
know we'd all like to see heart surgery over 5G, but something tells me
if you can afford it, the hospital can afford some fibre :-).

Perhaps M2M may have a use-case, but that's working reasonably well on
4G today, unless we expect to see a massive jump in performance with the
marginal improvement in radio latency between device and 5G tower.


>
> Another side is that the software engineers working on these Apps have
> a lot more prioritized items/things to develop (real core functions)
> so they will delay this transformation.

This is the crux of the issue.

Mark.

Re: BGP route hijack by AS10990

[Mark Tinka]

On 2/Aug/20 19:22, Darrell Budic wrote:
> Oh uh, I’m getting close to getting RPKI going on my mx204s, or was until you 
> posted that. What’s the story there, and perhaps which junos version?

None that I know if.

We have it working well (RPKI + ROV) on MX204's running Junos 19.2.

Curious to hear about Baldur's bug.

Mark.

Re: Has virtualization become obsolete in 5G?

[Etienne-Victor Depasquale]

>
> Still not sure how this will work considering a great deal of the global
> Internet is for services that live on the public Internet, and many
> specialized/private services would typically still run over fibre.
>

Is the following extract from this Heavy Reading white paper
,
useful?

" For transport network slicing,
operators strongly prefer soft slicing with virtual private networks
(VPNs),
regardless of the VPN flavor.
Ranking at the top of the list was Layer 3 VPNs (selected by 66% of
respondents),
but Layer 2 VPNs, Ethernet VPNs (EVPNs), and segment routing
also ranked highly at 47%, 46%, and 46%, respectively.
The point is underscored by the low preferences among all of the hard
slicing technologies—
those that physically partition resources among slices.
Hard slicing options formed the bottom tier among preferences."

Etienne

On Mon, Aug 3, 2020 at 7:42 AM Mark Tinka  wrote:

>
>
> On 2/Aug/20 06:51, Ahmed elBorno wrote:
> > Maybe I am off topic a little bit here and i'd like to be educated if
> > i am wrong but I think those 5G applications will move from VMs into
> > containers/microservices when their vendors see a business case to
> > rearchitect them, maybe its already happening as we speak.
>
> I'm still trying to figure out what "these 5G applications" are :-).
>
>
> >
> > On the other side of that coin is that product managers of these 5G
> > apps seeing the margins on their apps diminish when they slice them to
> > a form that allows other "orchestrators" to deploy them.
>
> My understanding of "network slicing" is that an operator lets an MVNO
> ride their network (happens today already), and that MVNO can further
> "slice" their portion of the operators network to deliver different
> performance levels for the different services they offer down to the
> end-user.
>
> Still not sure how this will work considering a great deal of the global
> Internet is for services that live on the public Internet, and many
> specialized/private services would typically still run over fibre. I
> know we'd all like to see heart surgery over 5G, but something tells me
> if you can afford it, the hospital can afford some fibre :-).
>
> Perhaps M2M may have a use-case, but that's working reasonably well on
> 4G today, unless we expect to see a massive jump in performance with the
> marginal improvement in radio latency between device and 5G tower.
>
>
> >
> > Another side is that the software engineers working on these Apps have
> > a lot more prioritized items/things to develop (real core functions)
> > so they will delay this transformation.
>
> This is the crux of the issue.
>
> Mark.
>
>

-- 
Ing. Etienne-Victor Depasquale
Assistant Lecturer
Department of Communications & Computer Engineering
Faculty of Information & Communication Technology
University of Malta
Web. https://www.um.edu.mt/profile/etiennedepasquale