FCC emergency waiver: Jewish Community Centers Calling Party Number Identification

[Sean Donelan]

The FCC granted an emergency temporary waiver to telecommunication 
carriers serving Jewish Community Centers, allowing access to the 
Caller-ID (Calling Party Number Identification) normally blocked at the 
calling party's request (i.e. star-67).


Although per call Call-Trace (i.e. star-57) and permanent Trap-and-Trace 
court orders also report the Caller-ID and other call information, such 
as ANI to law enforcement; the FCC occasionally granted similar 
waivers in the past.


Obviously this doesn't help with spoofed calling numbers.

https://www.fcc.gov/document/fcc-grants-emergency-waiver-help-protect-jewish-community-centers

Re: google ipv6 routes via cogent

[Jeremy Austin]

On Fri, Mar 3, 2017 at 5:05 PM, Job Snijders  wrote:

> > There are, of course, corner cases. But in general, single-homed
> > people shouldn’t be using BGP.
>
> There are numerous reasons to use BGP when single-homed:
>
> - as preparation to multi-home in the (near) future
> - ability to quickly change providers
> - to use BGP based blackholing features
> - to save time on provisioning work (adding new prefixes becomes a
>   matter of just announcing and updating IRR/RPKI).
> - loadbalanacing / loadsharing across multiple links
> - ability to use bgp communities for traffic engineering
>
> In other words, if you have your own IP space, I'd recommend to get your
> own ASN and use BGP.


I concur with Job.

If you are single-homed but care about having proper L3 redundancy (not
just VRRP or equivalent), BGP is a must.

ARIN has a policy to allow this, but it is not spelled out with an excess
of clarity. I suspect it is not often used; see NRPM section 5.

-- 
Jeremy Austin

Re: google ipv6 routes via cogent

[Job Snijders]

On Fri, Mar 03, 2017 at 09:42:04AM -0500, Patrick W. Gilmore wrote:
> On Mar 3, 2017, at 7:00 AM, Nick Hilliard  wrote:
> > Niels Bakker wrote:
> >> As I explained in the rest of my email that you conveniently didn't
> >> quote, it's so that you can selectively import routes from all your
> >> providers in situations where your router cannot handle a full table.
> > 
> > it can also break horribly in situations where the provider is providing
> > "transit" but doesn't provide full transit.
> > 
> > OTOH, if you are single-homed, it is highly advisable to accept a
> > default, the reason being that most transit providers provide bgp
> > communities with "don't advertise to customers" semantics.  So if you're
> > single-homed and use a full dfz feed without default route, you will not
> > have full connectivity to all the routes available from the transit
> > provider.

Correct.

> If you are single-homed, there is no need for BGP at all.

That is very strongly worded, and in plenty of cases a false assertion.

> And injecting your ASN into the table is probably not terribly useful
> to everyone else’s FIB.

ASNs don't have anything to do with FIB.

> There are, of course, corner cases. But in general, single-homed
> people shouldn’t be using BGP.

There are numerous reasons to use BGP when single-homed:

- as preparation to multi-home in the (near) future
- ability to quickly change providers
- to use BGP based blackholing features
- to save time on provisioning work (adding new prefixes becomes a
  matter of just announcing and updating IRR/RPKI).
- loadbalanacing / loadsharing across multiple links
- ability to use bgp communities for traffic engineering

In other words, if you have your own IP space, I'd recommend to get your
own ASN and use BGP.

Kind regards,

Job

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG,
MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 04 Mar, 2017

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  639225
Prefixes after maximum aggregation (per Origin AS):  248678
Deaggregation factor:  2.57
Unique aggregates announced (without unneeded subnets):  307752
Total ASes present in the Internet Routing Table: 56403
Prefixes per ASN: 11.33
Origin-only ASes present in the Internet Routing Table:   48853
Origin ASes announcing only one prefix:   21709
Transit ASes present in the Internet Routing Table:7550
Transit-only ASes present in the Internet Routing Table:207
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  42
Max AS path prepend of ASN ( 22394)  39
Prefixes from unregistered ASNs in the Routing Table:68
Numnber of instances of unregistered ASNs:   69
Number of 32-bit ASNs allocated by the RIRs:  17548
Number of 32-bit ASNs visible in the Routing Table:   13633
Prefixes from 32-bit ASNs in the Routing Table:   55318
Number of bogon 32-bit ASNs visible in the Routing Table:44
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:397
Number of addresses announced to Internet:   2836585604
Equivalent to 169 /8s, 18 /16s and 220 /24s
Percentage of available address space announced:   76.6
Percentage of allocated address space announced:   76.6
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   98.5
Total number of prefixes smaller than registry allocations:  213156

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   174750
Total APNIC prefixes after maximum aggregation:   49968
APNIC Deaggregation factor:3.50
Prefixes being announced from the APNIC address blocks:  174086
Unique aggregates announced from the APNIC address blocks:71703
APNIC Region origin ASes present in the Internet Routing Table:7887
APNIC Prefixes per ASN:   22.07
APNIC Region origin ASes announcing only one prefix:   2205
APNIC Region transit ASes present in the Internet Routing Table:   1123
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 41
Number of APNIC region 32-bit ASNs visible in the Routing Table:   2726
Number of APNIC addresses announced to Internet:  760850308
Equivalent to 45 /8s, 89 /16s and 167 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-137529
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:194786
Total ARIN prefixes after maximum aggregation:93195
ARIN Deaggregation factor: 2.09
Prefixes being announced from the ARIN address blocks:   197227
Unique aggregates announced from the ARIN address blocks: 90282
ARIN Region origin ASes present in the Internet Routing Table:17817
ARIN Prefixes per ASN:

Re: Qwest/CenturyLink BGP contact?

[Bryan Holloway]

Someone has reached out -- I'm good to go. Thanks all!


On 3/2/17 1:11 PM, Bryan Holloway wrote:

Hello all,

If someone from Qwest/Centurylink is lurking, could you contact me
off-list?

You are advertising a /24 out of a recently acquired /16, and I've been
unsuccessful reaching anyone.

Thanks!
- bryan

Re: google ipv6 routes via cogent

[Patrick W. Gilmore]

On Mar 3, 2017, at 7:00 AM, Nick Hilliard  wrote:
> 
> Niels Bakker wrote:
>> As I explained in the rest of my email that you conveniently didn't
>> quote, it's so that you can selectively import routes from all your
>> providers in situations where your router cannot handle a full table.
> 
> it can also break horribly in situations where the provider is providing
> "transit" but doesn't provide full transit.
> 
> OTOH, if you are single-homed, it is highly advisable to accept a
> default, the reason being that most transit providers provide bgp
> communities with "don't advertise to customers" semantics.  So if you're
> single-homed and use a full dfz feed without default route, you will not
> have full connectivity to all the routes available from the transit
> provider.

If you are single-homed, there is no need for BGP at all. And injecting your 
ASN into the table is probably not terribly useful to everyone else’s FIB.

There are, of course, corner cases. But in general, single-homed people 
shouldn’t be using BGP.

-- 
TTFN,
patrick

Re: google ipv6 routes via cogent

[Niels Bakker]

* n...@foobar.org (Nick Hilliard) [Fri 03 Mar 2017, 13:02 CET]:

Niels Bakker wrote:
As I explained in the rest of my email that you conveniently 
didn't quote, it's so that you can selectively import routes from 
all your providers in situations where your router cannot handle a 
full table.


it can also break horribly in situations where the provider is 
providing "transit" but doesn't provide full transit.


You don't need to import them into your border router's FIB.  It's 
always good to be able to change your own routing policy without 
having to consult your upstream's NOC.



-- Niels.

Re: google ipv6 routes via cogent

[Nick Hilliard]

Niels Bakker wrote:
> As I explained in the rest of my email that you conveniently didn't
> quote, it's so that you can selectively import routes from all your
> providers in situations where your router cannot handle a full table.

it can also break horribly in situations where the provider is providing
"transit" but doesn't provide full transit.

OTOH, if you are single-homed, it is highly advisable to accept a
default, the reason being that most transit providers provide bgp
communities with "don't advertise to customers" semantics.  So if you're
single-homed and use a full dfz feed without default route, you will not
have full connectivity to all the routes available from the transit
provider.

Nick

Re: google ipv6 routes via cogent

[Niels Bakker]

* how...@leadmon.net (Howard Leadmon) [Fri 03 Mar 2017, 01:06 CET]:

On 3/2/2017 2:57 PM, Niels Bakker wrote:

You should ask for full routes from all your providers + a default.


 If you taking full routes from everyone, why would you need a
default?   If they don't show a route for it, they probably can't reach
it.   I don't think I have run with a default route external for many
years, and so far it hasn't bit me yet..


As I explained in the rest of my email that you conveniently didn't 
quote, it's so that you can selectively import routes from all your 
providers in situations where your router cannot handle a full table.



-- Niels.