Hi Owen,
Op 26 jan. 2014, om 05:36 heeft Owen DeLong het volgende
geschreven:
> On Jan 25, 2014, at 13:59 , Sander Steffann wrote:
>
>> Hi,
>>
>>> […] But, when that happens ARIN will only have the 'Dedicated IPv4 block to
>>> facilitate IPv6 Deployment' [1] left, and it will use 'a minimum
On Jan 25, 2014, at 13:59 , Sander Steffann wrote:
> Hi,
>
>> Yeah, its been a while since I had to get involved in this. We have a
>> customer with their own IPv4 allocation that wants us to announce a /27 for
>> them. Back in "the day", it was /24 or larger or all bets were off. Is
>> that
Good stuff on this topic assembled by Barry Greene here:
http://confluence.senki.org/pages/viewpage.action?pageId=1474569
Tony
On Sat, Jan 25, 2014 at 7:57 PM, Chris Grundemann wrote:
> Perhaps instead of trying to do this as a new independent activity (with
> all of the difficulties that entai
Perhaps instead of trying to do this as a new independent activity (with
all of the difficulties that entails), the community would be better served
by documenting this information as a BCOP or two or three???
>>> http://bcop.nanog.org/ <<<
$0.02
~Chris
On Sun, Jan 26, 2014 at 4:08 AM, Jay As
Hi Jimmy,
> There aren't any /27 or /28 Allocations from ARIN to an ISP
> A /28 is longer than the ARIN Minimum allocation block size of /22, and
> longer than the minimum transfer size of a /24 block.
Now: yes. Soon: no. Read https://www.arin.net/policy/nrpm.html#four10
Sander
On 25/01/2014 22:50, Randy Bush wrote:
> do we have a chat with robert or push an alternative so that the wg is
> pushed to compromise?
i get the impression that Robert realises that the current draft is
unworkably complicated.
Nick
On Sat, Jan 25, 2014 at 4:15 PM, Sander Steffann wrote:
>
> Sure, but the text I quoted is about ARIN allocations, so ARIN -> ISP. So
> the /28 is not provider-independent. It *is* the provider... And yes: I
> think this will become a mess in ARIN land :(
>
There aren't any /27 or /28 Allocation
> http://tools.ietf.org/search/draft-raszuk-wide-bgp-communities-03
> To me, that draft looks hugely complicated, like everything you
> could possibly think of was thrown in.
do we have a chat with robert or push an alternative so that the wg is
pushed to compromise?
randy
I would imagine this should be announced with the larger block owner.
On Jan 25, 2014 2:19 PM, "Drew Linsalata" wrote:
> Yeah, its been a while since I had to get involved in this. We have a
> customer with their own IPv4 allocation that wants us to announce a /27 for
> them. Back in "the day",
Hi,
Op 25 jan. 2014, om 23:05 heeft Jeff Kell het volgende
geschreven:
> (snip)
>
> I doubt that anything > /24 will ever be eligible as a "portable"
> provider independent block. If within a provider, you can slice and
> dice as you wish.
Sure, but the text I quoted is about ARIN allocation
(snip)
I doubt that anything > /24 will ever be eligible as a "portable"
provider independent block. If within a provider, you can slice and
dice as you wish.
Jeff
Hi,
> Yeah, its been a while since I had to get involved in this. We have a
> customer with their own IPv4 allocation that wants us to announce a /27 for
> them. Back in "the day", it was /24 or larger or all bets were off. Is
> that still the case now?
This is still the case today.
I wonder w
On Sat, 25 Jan 2014, Drew Linsalata wrote:
Yeah, its been a while since I had to get involved in this. We have a
customer with their own IPv4 allocation that wants us to announce a /27 for
them. Back in "the day", it was /24 or larger or all bets were off. Is
that still the case now?
Things
On Sat, Jan 25, 2014 at 4:17 PM, Drew Linsalata
wrote:
> Yeah, its been a while since I had to get involved in this. We have a
> customer with their own IPv4 allocation that wants us to announce a /27 for
> them. Back in "the day", it was /24 or larger or all bets were off. Is
> that still the c
Yes, a /27 is too small. You need at least a /24.
On Jan 25, 2014, at 9:17 PM, Drew Linsalata wrote:
> Yeah, its been a while since I had to get involved in this. We have a
> customer with their own IPv4 allocation that wants us to announce a /27 for
> them. Back in "the day", it was /24 or la
On 1/25/14, 13:17, Drew Linsalata wrote:
Yeah, its been a while since I had to get involved in this. We have a
customer with their own IPv4 allocation that wants us to announce a /27 for
them. Back in "the day", it was /24 or larger or all bets were off. Is
that still the case now?
/24 hasn
Yeah, its been a while since I had to get involved in this. We have a
customer with their own IPv4 allocation that wants us to announce a /27 for
them. Back in "the day", it was /24 or larger or all bets were off. Is
that still the case now?
I would support that.
http://tools.ietf.org/search/draft-raszuk-wide-bgp-communities-03
How would you modify it?
To me, that draft looks hugely complicated, like everything you
could possibly think of was thrown in. I would support a simplified
version (and be able to code it without bugs) if it c
Well, coming up with a Mediawiki registration protocol that's hard to
spam is apparently more difficult than I'd thought.
For the moment, anyone who wants to contribute to the wiki, and to the
expanded deployment of BCP38, is invited to toss a note to moderator [at]
bcp38.info with a username, an
A path to a destination must be loop free, irrespectively.
So it is not a combination of multiple but rather a list of loop free paths to
a destination where any other metrics are used as tie-breakers.
Another story - how do you get all that state distributed, inter-area cases,
how do you make it
+1
On Jan 24, 2014 12:41 PM, "Owen DeLong" wrote:
> Some networks I have worked with took the average latency of each link and
> assigned that (with some constant multiple) as the interface cost.
>
> Of course this all fails miserably if you are using anything like MPLS
> underneath your OSPF.
>
Try this:
http://nocproject.org
On 25 Jan 2014, at 23:25, Mark Seiden wrote:
> i am aware of
>
> http://www.stanford.edu/group/networking/netdb
>
> which is used widely at stanford and few other places. it’s going through
> some improvements, according to
> my reading of the list. tilburg
On 25/01/2014 15:48, Sebastian Spies wrote:
> To make things worse: even if the IXPs ASN is 2-byte, I would assume,
> that RS implementors chose to interpret extended community strings as
> always being in the format 4-byte:2-byte (see RFC5668).
some ixp operators (e.g. me) are rather enthusiastic
i am aware of
http://www.stanford.edu/group/networking/netdb
which is used widely at stanford and few other places. it’s going through some
improvements, according to
my reading of the list. tilburg university appears to be adopting it. not
sure if it’s suitable mostly
for an ISP. it use
On Saturday, January 25, 2014 08:10:54 AM Graham Beneke
wrote:
> The auto-cost capability in some vendors devices seems to
> have left many people ignoring the link metrics within
> their IGP. From what I recall in the standards -
> bandwidth is one possible link metric but certainly not
> the on
I've used IPPlan in the past to keep track of both internal and
external assignments, and it worked really well. Super simple to use
and setup. It's a bit of a dated project, but it'll still work pretty
well.
I also just saw this:
http://phpipam.net/
It looks pretty slick. Haven't used it mys
Along related lines:
Anybody have any suggestions for good opensource tools for managing
blocks of IP addresses, and domain name assignments - ideally with hooks
for updating nameservers and registry databases? Last time I looked
everyone was still using either spreadsheets or high-priced pro
On Friday, January 24, 2014 10:59:19 PM Owen DeLong wrote:
> I wasn’t attempting to promote or discourage use of MPLS.
> I was merely endeavoring to point out that in an MPLS
> world, OSPF costs are not how you want to manage your
> traffic.
Again, only an issue when using RSVP-TE.
I'd recommend
On Friday, January 24, 2014 10:36:48 PM Owen DeLong wrote:
> Of course this all fails miserably if you are using
> anything like MPLS underneath your OSPF.
Specifically, fails miserably if you use RSVP-TE to build
your MPLS backbone.
LDP follows IGP cost (has to be manually enabled in Junos),
We decided against RT and use Redmine for tickets instead. We find Redmine
to be much more user-friendly.
On Jan 25, 2014 8:14 AM, "Franck Martin" wrote:
>
> On Jan 24, 2014, at 1:37 AM, Octavio Alfageme
> wrote:
>
> > Hello everyone,
> >
> > I work for a small service provider starting to offe
Am 25.01.2014 16:38, schrieb Bryan Socha:
> Re-reading, I was thinking of someone connecting to an IXP, not a new
> IXP needing a 2Byte.This is an interesting situation and you are
> correct, my comment was off topic.
Sorry for not mentioning the beef: Extended Communities effectively
leave 6
Re-reading, I was thinking of someone connecting to an IXP, not a new IXP
needing a 2Byte.This is an interesting situation and you are correct,
my comment was off topic.
*Bryan Socha*
Network Engineer
646.450.0472 | *br...@serverstack.com *
*ServerStack* | Scale Big
On Sat, Jan 25, 2014 a
On Sat, Jan 25, 2014 at 10:04:30AM -0500, Bryan Socha wrote:
> I have over 100,000 servers located in routing diverse datacenters
> with 4byte ASN numbers and have not had 1 problem or complaint related
> to the ASN for not able to communicate with the datacenter. The first
> 1 did make me really
I have over 100,000 servers located in routing diverse datacenters with
4byte ASN numbers and have not had 1 problem or complaint related to the
ASN for not able to communicate with the datacenter. The first 1 did make
me really nervous for all of the reasons already mentioned but turned out
to be
Dear Sebastian,
On Sat, Jan 25, 2014 at 02:56:16PM +0100, Sebastian Spies wrote:
> So here's the thing: IXPs usually implement N:M filtering based on
> standard community strings. As standard BGP communities support only 4
> bytes, this only works for IXPs with 2-byte ASNs and peers with 2-byte
>
>
> What happens, if the IXP uses a 4-byte ASN? RFC5668 (4-Octet AS Specific
> BGP Extended Community) defines : 2bytes>.
>
> I have been asking some IXP operators, about their practice and their
> reply was "4-byte ASNs are supported by our RS". What's your experience?
> Did you see IXPs, that do
Hi there,
as 2-byte ASNs are close to depletion (see NRO announcement this week),
we have come across a topic, that might influence the adoption of 4-byte
ASNs. First of all, we have no data or experience about 4-byte ASN
adoption and are therefore unable to evaluate, if we should rush for the
las
On Sat, Jan 25, 2014 at 03:20:07AM -0600, Jimmy Hess wrote:
> The 32 bits will be interpreted as the bits of an IPv4 address, which are
> always 4 numeric values (0 to 255) separated by dots.
Well, that's how they're listed in master files, anyway; that's the
only constraint RFC 1035 makes (s
On Sat, Jan 25, 2014 at 2:39 AM, Randy Bush wrote:
> > I should be clear that there are no bangs (!) in dns.
>
> the dns is 8-bit clean. bangs, dots (not as separators), blanks, etc.
> are all valid. some applications may have trouble with use of some of
> these :)
>
Not in the right-hand side
> I should be clear that there are no bangs (!) in dns.
the dns is 8-bit clean. bangs, dots (not as separators), blanks, etc.
are all valid. some applications may have trouble with use of some of
these :)
randy
40 matches
Mail list logo
