Hi,

Yes, nice.  But... It does not address the case when this is not the ISPs 
customers but the ISP (read content provider) that operates globally but 
without a network interconnecting their routers.  They then advertise a /24 v4 
and /48 v6 at each Internet exchange that they are connected to.  That is 
"fine" for driving router.  The "problem" with this design is that they cant 
announce their /32 as they are not running a iBGP mesh.  I have seen a number 
of content providers doing this by design, and in the context of their business 
I can understand why and see it makes some sense.  The only problem comes with 
the prefixes ending up under the minimum prefix size for the block they are in.

Now when this is a large content provider and we all want the peering, then we 
relax the filters, fine, but why one rule for them and another for everyone 
else in the same /12 block.  Would it not make sense for the RIRs to assign a 
/12 as issuable in /32, /29 to content providers who will specifically 
deagregate to /48 with no internal network.

That solves the filtering problem, doesn't force these networks to put an iBGP 
network in place and lets everyone who does run a network "properly" to 
announce the proper aggregate blocks / covering routes with more specifics if 
we have to have them for routing purposes.

A separate /12 for the "island" type networks would immediately make this 
problem disappear.

Am I being overly simplistic?

Ben

-----Original Message-----
From: Frank Habicht [mailto:ge...@geier.ne.tz] 
Sent: 14 November 2012 16:56
To: nanog@nanog.org
Subject: Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 
RIR minimums.

On 11/14/2012 6:02 PM, William Herrin wrote:

> and send a polite email to the POC to the effect of, "Please beware 
> that because you have not offered a covering route matching your 
> allocation, your IPv6 network is not reachable from ours. IPv6 is not
> IPv4: end users requiring /48s for multihoming should get them 
> directly from the RIR. For complete Internet connectivity, we strongly 
> encourage you to offer a covering route."

like that.
Frank




Reply via email to