Re: IPv4 address length technical design

[Eugen Leitl]

On Wed, Oct 03, 2012 at 06:59:20PM -0400, valdis.kletni...@vt.edu wrote:

> Where's Noel Chiappa when you need him?
> 
> >   (2)  The new protocol will use  variable-length address for the Host
> > portion, such as  used in the addresses of CLNP,
> 
> This also was considered during the IPv6 design phase, and the router
> designers had a collective cow, as it makes ASIC design a whole lot more
> interesting.  And back then, line speed was a lot lower than it is now...
> 
> Not saying it can't be done - but you're basically going to have to do CLNP
> style handling at 400Gbits or 1Tbit.  Better get those ASIC designers a *lot*
> of caffeine, they're gonna need it...

Except that these will be pure photonic networks, and apart from optical
delay lines for your packet buffer you'd better be able to make a routing 
(switching) decision while few bits of the header have streamed by your
photonic router circuit.

There is no time for any table look-ups, obviously.

And optical gates are *really* expensive, so better use few of
them. And don't add too many gate delays, too.

Above describes your setting for the next protocol. There is not
a lot of leeway in design space, I'm afraid.

Re: IPv4 address length technical design

[Barry Shein]

On October 3, 2012 at 17:09 j...@baylink.com (Jay Ashworth) wrote:
 > 
 > So the address space for IPv8 will be...
 > 

Variable.

  -b

Re: IPv4 address length technical design

[George Herbert]

On Wed, Oct 3, 2012 at 4:15 PM, Owen DeLong  wrote:
>
> On Oct 3, 2012, at 3:49 PM, Jimmy Hess  wrote:
>
>> On 10/3/12, Jay Ashworth  wrote:
>>> So the address space for IPv8 will be...
>>> 
>>
>> In 100 years, when we start to run out of IPv6 addresses,  possibly we
>> will have learned our lesson and done  two things:
>>
>>  (1)   Stopped  mixing the Host identification and the Network
>> identification into the same bit field;   instead  every packet gets a
>> source network address,  destination network address, AND  an
>> additional  tuple of   Source host address,   destination host
>> address;  residing in completely separate address spaces,  with  no
>> "Netmasks",  "Prefix lengths", or other comingling of  network
>> addresses and host address spaces.
>>
>
> Agreed, mostly.
>
> Prefix lengths can still be useful for route summarization and it would
> be useful to have separate segments of the network address, such as
> Autonomous System Number, Intra-AS Organizational Identifier, and
> Intra-Organizational Network, for example. It might be useful to use
> prefix lengths in those cases to allow for variability in the boundary
> between these identifiers.
>
>> And
>>  (2)  The new protocol will use  variable-length address for the Host
>> portion, such as  used in the addresses of CLNP,  with a convention of
>> a specified length,  instead of a hardwired specific limit  that comes
>> from using a permanently  fixed-width field.
>>
>
> On this, I disagree… Once host identifiers are no longer dependent on or
> related to topology, there's no reason a reasonable fixed-length cannot
> suffice.
>
>> Need more bits?   No protocol definition change required.
>>
>
> Nope, just new ASICS everywhere and no clear way to identify where they
> are or are not deployed and…

A regrettably serious response:

There are some fundamental questions about areas of computer usage,
engineering, and science that will affect what "the next protocol"
should look like.

Despite a couple of decades of frenetic work to mobility-ize our
protocols, we mostly didn't with IPv6; that may be the norm rather
than the design exception by $NEXTPROTOCOL.

Quantum computers may, or may not, be relevant to anything (including
possibly routing or switching) by $NEXTPROTOCOL days.

Supermassive parallelism may be relevant to routing or switching.

Moore's Law may peter out at some point with Silicon hitting
atom-count limits, or could continue somewhat further with nanowires
and graphene and the like, or something else completely could come
about.

Extremely low cost concerns may collapse the number of physical
devices in a computer / computing device, as we have see many cycles
of various system controllers or video controllers migrating into CPUs
or back out again as performance or chip cost concerns / fab
technology pushed the optimization point one way or the other.  This
could affect switch and router cost optimization as well.


We can (probably safely) say that within the next decade there is no
sign of a technical or business driver for $NEXTPROTOCOL bubbling over
our feet; by the time that it becomes necessary or relevant, all the
ASICS we have out there now will be obsolete.  Whether they're just
faster smaller ASICS or some form of interface we cannot currently
accurately predict, I have no idea, but I would rather not limit our
conceptualization of 20-100 year timeframe solutions to "Today, but
faster".  If we go back to 1992, it is almost completely an accident
that winning technologies in many areas today are still recognizable
to the computer people of that era.


-- 
-george william herbert
george.herb...@gmail.com

Re: IPv4 address length technical design

[Owen DeLong]

On Oct 3, 2012, at 3:49 PM, Jimmy Hess  wrote:

> On 10/3/12, Jay Ashworth  wrote:
>> So the address space for IPv8 will be...
>> 
> 
> In 100 years, when we start to run out of IPv6 addresses,  possibly we
> will have learned our lesson and done  two things:
> 
>  (1)   Stopped  mixing the Host identification and the Network
> identification into the same bit field;   instead  every packet gets a
> source network address,  destination network address, AND  an
> additional  tuple of   Source host address,   destination host
> address;  residing in completely separate address spaces,  with  no
> "Netmasks",  "Prefix lengths", or other comingling of  network
> addresses and host address spaces.
> 

Agreed, mostly.

Prefix lengths can still be useful for route summarization and it would
be useful to have separate segments of the network address, such as
Autonomous System Number, Intra-AS Organizational Identifier, and
Intra-Organizational Network, for example. It might be useful to use
prefix lengths in those cases to allow for variability in the boundary
between these identifiers.

> And
>  (2)  The new protocol will use  variable-length address for the Host
> portion, such as  used in the addresses of CLNP,  with a convention of
> a specified length,  instead of a hardwired specific limit  that comes
> from using a permanently  fixed-width field.
> 

On this, I disagree… Once host identifiers are no longer dependent on or
related to topology, there's no reason a reasonable fixed-length cannot
suffice.

> Need more bits?   No protocol definition change required.
> 

Nope, just new ASICS everywhere and no clear way to identify where they
are or are not deployed and…

Owen

Re: IPv4 address length technical design

[Cutler James R]

On Oct 3, 2012, at 6:49 PM, Jimmy Hess  wrote:
> On 10/3/12, Jay Ashworth  wrote:
>> So the address space for IPv8 will be...
>> 
> 
> In 100 years, when we start to run out of IPv6 addresses,  possibly we
> will have learned our lesson and done  two things:
> 
>  (1)   Stopped  mixing the Host identification and the Network
> identification into the same bit field;   instead  every packet gets a
> source network address,  destination network address, AND  an
> additional  tuple of   Source host address,   destination host
> address;  residing in completely separate address spaces,  with  no
> "Netmasks",  "Prefix lengths", or other comingling of  network
> addresses and host address spaces.
> 
> And
>  (2)  The new protocol will use  variable-length address for the Host
> portion, such as  used in the addresses of CLNP,  with a convention of
> a specified length,  instead of a hardwired specific limit  that comes
> from using a permanently  fixed-width field.
> 
> Need more bits?   No protocol definition change required.
> 
> 
>> Cheers,
>> -- jra
> --
> -JH
> 

I suggest that the DNS name space should be considered to be an "hierarchical 
host address space" thus satisfying (1) and making (2) moot.

Re: IPv4 address length technical design

[Cutler James R]

On Oct 3, 2012, at 4:17 PM, Dave Crocker  wrote:
 Is anyone aware of any historical documentation relating to the
 choice of 32
>>> bits for an IPv4 address?
> ...
>> Actually that was preceded by RFC 760, which in turn was a derivative
>> of IEN 123. I believe the answer to the original question is
> ...
> 
> 
> My theory is that there is a meta-rule to make new address spaces have 4
> times as many bits as the previous generation.
> 
> We have three data points to establish this for the Internet, and that's
> the minimum needed to run a correlation:  Arpanet, IPv4, IPv6...
> 
> d/


Didn't work for DecNet Phase III, Decnet Phase IV, Decnet Phase V (8, 16, 128).

Re: IPv4 address length technical design

[David Conrad]

On Oct 3, 2012, at 3:59 PM, valdis.kletni...@vt.edu wrote:
> On Wed, 03 Oct 2012 17:49:56 -0500, Jimmy Hess said:
>>  (1)   Stopped  mixing the Host identification and the Network
>> identification into the same bit field;
> 
> Where's Noel Chiappa when you need him?

Saying "I told you so" I suspect.

>>  (2)  The new protocol will use  variable-length address for the Host
>> portion, such as  used in the addresses of CLNP,
> This also was considered during the IPv6 design phase, and the router
> designers had a collective cow, as it makes ASIC design a whole lot more
> interesting.

Where are Tony Li, Paul Traina, and the whole TUBA orchestra when you need 
them?  :-)

Regards,
-drc

Re: IPv4 address length technical design

[Valdis . Kletnieks]

On Wed, 03 Oct 2012 17:49:56 -0500, Jimmy Hess said:

>   (1)   Stopped  mixing the Host identification and the Network
> identification into the same bit field;   instead  every packet gets a
> source network address,  destination network address, AND  an
> additional  tuple of   Source host address,   destination host
> address;  residing in completely separate address spaces,  with  no
> "Netmasks",  "Prefix lengths", or other comingling of  network
> addresses and host address spaces.

Where's Noel Chiappa when you need him?

>   (2)  The new protocol will use  variable-length address for the Host
> portion, such as  used in the addresses of CLNP,

This also was considered during the IPv6 design phase, and the router
designers had a collective cow, as it makes ASIC design a whole lot more
interesting.  And back then, line speed was a lot lower than it is now...

Not saying it can't be done - but you're basically going to have to do CLNP
style handling at 400Gbits or 1Tbit.  Better get those ASIC designers a *lot*
of caffeine, they're gonna need it...



pgpdw5TUCJmzT.pgp
Description: PGP signature

Re: IPv4 address length technical design

[Jimmy Hess]

On 10/3/12, Jay Ashworth  wrote:
> So the address space for IPv8 will be...
> 

In 100 years, when we start to run out of IPv6 addresses,  possibly we
will have learned our lesson and done  two things:

  (1)   Stopped  mixing the Host identification and the Network
identification into the same bit field;   instead  every packet gets a
source network address,  destination network address, AND  an
additional  tuple of   Source host address,   destination host
address;  residing in completely separate address spaces,  with  no
"Netmasks",  "Prefix lengths", or other comingling of  network
addresses and host address spaces.

And
  (2)  The new protocol will use  variable-length address for the Host
portion, such as  used in the addresses of CLNP,  with a convention of
a specified length,  instead of a hardwired specific limit  that comes
from using a permanently  fixed-width field.

Need more bits?   No protocol definition change required.


> Cheers,
> -- jra
--
-JH

Rogers.ca fiber contact

[Dennis Burgess]

Have a fiber circuit that is getting inconsistent speeds to the net L
Need an IPERF test on rogers network to verify bandwidth.  

 

Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS-
Second Edition  "

 Link Technologies, Inc -- Mikrotik & WISP Support Services

 Office: 314-735-0270   Website:
http://www.linktechs.net   - Skype: linktechs


 -- Create Wireless Coverage's with www.towercoverage.com
  - 900Mhz - LTE - 3G - 3.65 - TV
Whitespace  
5-Day Advanced RouterOS Workshop - Oct 8th 2012 - St. Louis, MO, USA
 

 

Re: IPv4 address length technical design

[Owen DeLong]

On Oct 3, 2012, at 12:22 PM, Izaac  wrote:

> On Wed, Oct 03, 2012 at 06:52:57PM +0200, Seth Mos wrote:
>> "Pick a number between this and that." It's the 80's and you can
>> still count the computers in the world. :)
> 
> And yet, almost concurrently, IEEE 802 went with forty-eight bits.  Go
> figure.  I'm pretty sure the explanation you're looking for is: It was
> with the word size of the most popular minis and micros at the time.
> 
IEEE 802 was expected to provide unique numbers for all computers ever built.

Internet was expected to provide unique numbers for all computers actively on 
the network.

Obviously, over time, the latter would be a declining percentage of the former 
since the former is increasing and never decrements while the latter could 
(theoretically) have a growth rate on either side of zero and certainly has 
some decrements even if the increments exceed the decrements.


Owen

RE: [j-nsp] Krt queue issues

[Naslund, Steve]

I think route retention might help in the event the table was cleared or
routing process restarted but I don't that it will help with a boot
because the table structures are being built as part of the system
initialization.  In reality, I would expect the static routes to get
installed very early as soon as the routing process comes up.  Since you
will need a route to your BGP neighbor (even though it may be directly
connected, it is still a route), routing has to be up BEFORE BGP
establishes and by definition your static routes will have to be up
before your BGP routes are ready.  How well your router responds to
traffic during an initial boot and during a 300,000 route update is
another story.  My experience with very large routers and tables is that
you will have a hard time guaranteeing user traffic will pass with very
much performance during an event like a full table rebuild.  Luckily
with the bandwidth we have these days and the CPU power on the routers,
it does not take that long to pull in a full internet table and begin
handling traffic.

Steven Naslund

-Original Message-
From: Jensen Tyler [mailto:jty...@fiberutilities.com] 
Sent: Wednesday, October 03, 2012 9:45 AM
To: nanog@nanog.org
Subject: RE: [j-nsp] Krt queue issues

Look into Static route retain. Should keep the route in the forwarding
table.

>From Jniper site
<<<
Route Retention

By default, static routes are not retained in the forwarding table when
the routing process shuts down. When the routing process starts up
again, any routes configured as static routes must be added to the
forwarding table again. To avoid this latency, routes can be flagged as
retain, so that they are kept in the forwarding table even after the
routing process shuts down. Retention ensures that the routes are always
in the forwarding table, even immediately after a system reboot.
>>>

Thanks,

Jensen Tyler
Sr Engineering Manager
Fiberutilities Group, LLC


-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Benny Amorsen
Sent: Wednesday, October 03, 2012 8:32 AM
To: Jared Mauch
Cc: Saku Ytti; juniper-...@puck.nether.net
Subject: Re: [j-nsp] Krt queue issues

Jared Mauch  writes:

> As far as the fallback 'default' route, if you are purchasing transit 
> from someone, you could consider a last-resort default pointed at 
> them. You can exclude routes like 10/8 etc by routing these to discard
> + install on your devices.

That only helps if the default gets installed first, though. If the
default has to wait at boot in the krt-queue behind the 300k+
Internet-routes, I have not really gained anything...

I suppose it is likely that a static default would be installed before
the BGP sessions even come up.


/Benny
___
juniper-nsp mailing list juniper-...@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

RE: IPv4 address length technical design

[Naslund, Steve]

Remember that at the time, IP was designed to be classful so having four 8 bit 
bytes was real convenient to look only at the bytes in the host portion of the 
address.  Class A meant three significant bytes, Class B had two significant 
bytes, and Class C had three significant bytes as far as the host portion of 
the address.  If we are looking for matches in a routing table it is much 
easier to search for an entire matching byte than to do it bitwise.  Even 
though systems had varying byte lengths, 8 was still the most common because it 
was the easiest to map extended ASCII into.

Now we could discuss whether there should have been more bytes but at the time 
no one had really envisioned the public deployment of this at the scales we see 
today.  Same reason IBM and Microsoft had barriers like 640k of RAM, no one 
just ever thought you would need more than that.

Steven Naslund

-Original Message-
From: Seth Mos [mailto:seth@dds.nl] 
Sent: Wednesday, October 03, 2012 11:53 AM
To: nanog@nanog.org
Subject: Re: IPv4 address length technical design

Op 3-10-2012 18:33, Kevin Broderick schreef:
> I'll add that in the mid-90's, in a University Of Washington lecture 
> hall, Vint Cerf expressed some regret over going with 32 bits.  
> Chuckle worthy and at the time, and a fond memory
> - K

"Pick a number between this and that." It's the 80's and you can still count 
the computers in the world. :)

It is/was a "experiment" and you have the choice between a really large and a 
larger number. Humans are not too good in comparing really large numbers. If it 
was ever decided to use a smaller value, for the size of the experiment it 
might have went quite different. The "safe" (larger) choice ended up bringing 
more pain.

As a time honored ritual, the temporary solution becomes the production 
solution.

Oops... And that was not quite what Mr Cerf meant to do.

Regards,

Seth

Re: IPv4 address length technical design

[George Herbert]

On Wed, Oct 3, 2012 at 2:19 PM, Scott Weeks  wrote:
>
>
> --- j...@baylink.com wrote:
> From: Jay Ashworth 
>
> So the address space for IPv8 will be...
> 
> -
>
>
> Jim says:
>
> "IPv8 - 43 bits (3+8+32)
>
> There is a natural routing hierarchy with IPv8
> addressing8 regions, 256 distribution centers
> in each region and full 32 bit Internets from there.
> IPv8 addresses can fit inside the IPv6 address fields."
>
>
>>;-)
> scott

One bit of network address, used to designate whether it is a
broadcast or single-host-recipient packet.

And 511 bit MAC addresses...

(L2 Uber Alles.  Routers are for the Weak.)


-- 
-george william herbert
george.herb...@gmail.com

Re: IPv4 address length technical design

[Scott Weeks]

--- j...@baylink.com wrote:
From: Jay Ashworth 

So the address space for IPv8 will be...

-


Jim says:

"IPv8 - 43 bits (3+8+32)

There is a natural routing hierarchy with IPv8
addressing8 regions, 256 distribution centers
in each region and full 32 bit Internets from there.
IPv8 addresses can fit inside the IPv6 address fields."


>;-)
scott

Re: IPv4 address length technical design

[Jay Ashworth]

- Original Message -
> From: "Dave Crocker" 

> My theory is that there is a meta-rule to make new address spaces have
> 4 times as many bits as the previous generation.
> 
> We have three data points to establish this for the Internet, and
> that's the minimum needed to run a correlation: Arpanet, IPv4, IPv6...

So the address space for IPv8 will be...


Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274

Re: IPv4 address length technical design

[Dave Crocker]

Is anyone aware of any historical documentation relating to the
choice of 32

bits for an IPv4 address?

...

Actually that was preceded by RFC 760, which in turn was a derivative
of IEN 123. I believe the answer to the original question is

...


My theory is that there is a meta-rule to make new address spaces have 4
times as many bits as the previous generation.

We have three data points to establish this for the Internet, and that's
the minimum needed to run a correlation:  Arpanet, IPv4, IPv6...

d/

--
 Dave Crocker
 Brandenburg InternetWorking
 bbiw.net

Re: IPv4 address length technical design

[William Herrin]

On Wed, Oct 3, 2012 at 3:22 PM, Izaac  wrote:
> On Wed, Oct 03, 2012 at 06:52:57PM +0200, Seth Mos wrote:
>> "Pick a number between this and that." It's the 80's and you can
>> still count the computers in the world. :)
>
> And yet, almost concurrently, IEEE 802 went with forty-eight bits.  Go
> figure.  I'm pretty sure the explanation you're looking for is: It was
> with the word size of the most popular minis and micros at the time.

It wasn't. At the time. But at some point people of vision figured out
that CPU word sizes would standardize on power-of-two powers of two.
Really helps when you want to align data elements in memory if exactly
2 16 bit integers fit in the 32 bit word and exactly 2 32 bit integers
fit in the 64 bit word. "And a half" is a phrase that makes life
miserable in both software development and hardware design.

IEEE figured it out later. The replacement for the MAC address is
EUI-64. I still haven't figured out Bell's excuse with ATM.

Regards,
Bill Herrin

-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: IPv4 address length technical design

[Valdis . Kletnieks]

On Wed, 03 Oct 2012 15:44:16 -0400, "Tony Patti" said:
>
> Perhaps worth noting (for the archives) that a significant part of the early
> ARPAnet was DECsystem-10's with 36-bit words.

And the -10s and -20s were the major reason RFCs refer to octets rather than 
bytes,
as they had a rather slippery notion of "byte" (anywhere from 6 to 9 bits, 
often multiple
sizes used *in the same program*).


pgpz78iTf2YW4.pgp
Description: PGP signature

RE: IPv4 address length technical design

[Tony Patti]

Perhaps worth noting (for the archives) that a significant part of the early
ARPAnet was DECsystem-10's with 36-bit words.

http://en.wikipedia.org/wiki/PDP-10

http://en.wikipedia.org/wiki/Email

Tony Patti
CIO
S. Walter Packaging Corp.


-Original Message-
From: George Herbert [mailto:george.herb...@gmail.com] 
Sent: Wednesday, October 03, 2012 3:28 PM
To: Tony Hain
Cc: nanog@nanog.org
Subject: Re: IPv4 address length technical design

On Wed, Oct 3, 2012 at 12:11 PM, Tony Hain  wrote:

It's worthwhile noting that the state of system (mini and
microcomputer) art at the time of the 1977 discussions was, for example, the
Intel 8085 (8-bit registers; the 16-bit 8086 was 1978) and 16-bit PDP-11s.
The 32-bit VAX 11/780 postdated these (announced October 77).

Yes, you can do 32 or 64 bit network addressing with smaller registers, but
there are tendencies to not think that way.

Re: IPv4 address length technical design

[George Herbert]

On Wed, Oct 3, 2012 at 12:22 PM, Izaac  wrote:
> On Wed, Oct 03, 2012 at 06:52:57PM +0200, Seth Mos wrote:
>> "Pick a number between this and that." It's the 80's and you can
>> still count the computers in the world. :)
>
> And yet, almost concurrently, IEEE 802 went with forty-eight bits.  Go
> figure.  I'm pretty sure the explanation you're looking for is: It was
> with the word size of the most popular minis and micros at the time.

The 48 bit MAC was 1980; notable that it was not primarily handled in
software / CPUs (ethernet key functionality is in dedicated interface
hardware, though the stack is MAC-aware obviously).  CPU register bit
length is less critical when you have a dedicated controller of
arbitrary bittedness handling MACs.


-- 
-george william herbert
george.herb...@gmail.com

Re: IPv4 address length technical design

[George Herbert]

On Wed, Oct 3, 2012 at 12:11 PM, Tony Hain  wrote:
>> Sadiq Saif [mailto:sa...@asininetech.com] wrote:
>>
>> On Wed, Oct 3, 2012 at 12:13 PM, Chris Campbell 
>> wrote:
>> > Is anyone aware of any historical documentation relating to the choice of 
>> > 32
>> bits for an IPv4 address?
>> >
>> > Cheers.
>>
>> I believe the relevant RFC is RFC 791 - https://tools.ietf.org/html/rfc791
>
> Actually that was preceded by RFC 760, which in turn was a derivative of IEN 
> 123. I believe the answer to the original question is partially available on 
> a series of pages starting at :   
> http://www.networksorcery.com/enp/default1101.htm
> IEN 2 is likely to be of particular interest ...

It's worthwhile noting that the state of system (mini and
microcomputer) art at the time of the 1977 discussions was, for
example, the Intel 8085 (8-bit registers; the 16-bit 8086 was 1978)
and 16-bit PDP-11s.  The 32-bit VAX 11/780 postdated these (announced
October 77).

Yes, you can do 32 or 64 bit network addressing with smaller
registers, but there are tendencies to not think that way.


-- 
-george william herbert
george.herb...@gmail.com

Re: IPv4 address length technical design

[Izaac]

On Wed, Oct 03, 2012 at 06:52:57PM +0200, Seth Mos wrote:
> "Pick a number between this and that." It's the 80's and you can
> still count the computers in the world. :)

And yet, almost concurrently, IEEE 802 went with forty-eight bits.  Go
figure.  I'm pretty sure the explanation you're looking for is: It was
with the word size of the most popular minis and micros at the time.

-- 
. ___ ___  .   .  ___
.  \/  |\  |\ \
.  _\_ /__ |-\ |-\ \__

RE: IPv4 address length technical design

[Tony Hain]

> Sadiq Saif [mailto:sa...@asininetech.com] wrote:
>
> On Wed, Oct 3, 2012 at 12:13 PM, Chris Campbell 
> wrote:
> > Is anyone aware of any historical documentation relating to the choice of 32
> bits for an IPv4 address?
> >
> > Cheers.
> 
> I believe the relevant RFC is RFC 791 - https://tools.ietf.org/html/rfc791

Actually that was preceded by RFC 760, which in turn was a derivative of IEN 
123. I believe the answer to the original question is partially available on a 
series of pages starting at :   
http://www.networksorcery.com/enp/default1101.htm 
IEN 2 is likely to be of particular interest ... 

Re: Internet routing table "completeness" monitoring?

[Justin M. Streiner]

On Wed, 3 Oct 2012, Christopher Morrow wrote:


is a threshold helpful here? (well, it's helpful to a point at least)
what if your neighbour starts deaggragating (or sending you their
internal deaggragates) in place of 50k real routes? no alarm, no
'change' from a numbers perspective, but certainly a traffic shift and
reach-ability change :(


As long as you have some control over the number of polling intervals 
between the detection of a noteworthy change and sending an alarm. 
Otherwise, there is a real danger of your NOC having to investigate a lot 
of noisy alerts.  If that persists for too long, the NOC will grow tired 
of responding to these alerts, and send them all to the bit bucket, or 
implement their own polling thresholds that meet their needs more 
effectively.


If a network you have no business relationship with and several AS hops 
away from you goes away, how much effort do you want to expend 
investigating that?  That probably depends on your customers.  If you see 
a few hundred routes disappear and determine them to be for an ISP on the 
other side of the planet, that's one thing.  If your view of something 
like Google or Facebook suddenly disappears, that could be another thing 
entirely ;)



Isn't a speed-of-change threshold also interesting here?


+1 on that :)

jms

Re: IPv4 address length technical design

[Robert E. Seastrom]

Chris Campbell  writes:

> Is anyone aware of any historical documentation relating to the choice of 32 
> bits for an IPv4 address?
>
> Cheers.

8 bit host identifiers had proven to be too short...  :)

-r

Re: IPv4 address length technical design

[Seth Mos]

Op 3-10-2012 18:33, Kevin Broderick schreef:

I'll add that in the mid-90's, in a University Of Washington lecture hall, Vint 
Cerf expressed some regret over going with 32 bits.  Chuckle worthy and at the 
time, and a fond memory
- K


"Pick a number between this and that." It's the 80's and you can still 
count the computers in the world. :)


It is/was a "experiment" and you have the choice between a really large 
and a larger number. Humans are not too good in comparing really large 
numbers. If it was ever decided to use a smaller value, for the size of 
the experiment it might have went quite different. The "safe" (larger) 
choice ended up bringing more pain.


As a time honored ritual, the temporary solution becomes the production 
solution.


Oops... And that was not quite what Mr Cerf meant to do.

Regards,

Seth

Re: IPv4 address length technical design

[Kevin Broderick]

I'll add that in the mid-90's, in a University Of Washington lecture hall, Vint 
Cerf expressed some regret over going with 32 bits.  Chuckle worthy and at the 
time, and a fond memory
- K

Sadiq Saif  wrote:

>On Wed, Oct 3, 2012 at 12:13 PM, Chris Campbell 
>wrote:
>> Is anyone aware of any historical documentation relating to the
>choice of 32 bits for an IPv4 address?
>>
>> Cheers.
>
>I believe the relevant RFC is RFC 791 -
>https://tools.ietf.org/html/rfc791
>
>--
>Sadiq S
>O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

Re: IPv4 address length technical design

[Sadiq Saif]

On Wed, Oct 3, 2012 at 12:13 PM, Chris Campbell  wrote:
> Is anyone aware of any historical documentation relating to the choice of 32 
> bits for an IPv4 address?
>
> Cheers.

I believe the relevant RFC is RFC 791 - https://tools.ietf.org/html/rfc791

-- 
Sadiq S
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

IPv4 address length technical design

[Chris Campbell]

Is anyone aware of any historical documentation relating to the choice of 32 
bits for an IPv4 address?

Cheers.

Re: Internet routing table "completeness" monitoring?

[Andrew Gallo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 10/3/2012 10:16 AM, William F. Maton Sotomayor wrote:
> On Wed, 3 Oct 2012, Joseph Jackson wrote:
>
>> I have cacti graph the amount of prefixes announced and withdrawn
from a BGP peer on each BGP router.
>
> +1
>
> Note that not all router OSs support fetching data like that via SNMP.
>
> We use a custom built thing internally that does this two, which we
then tack on an alert threshold for. So if a downstream peer sends us
less than that, we get an alert. Handy for those times when they call
and ask us what we did to their network. :-)
>
> Prior to that, we had a script which whould login, munge the 'show ip
bgp summary' table output, figure out the deltas and graph or report as
needed on a particularly troublesome peer.
>
>>
>>
>>
>> -Original Message-
>> From: ML [mailto:m...@kenweb.org]
>> Sent: Tuesday, October 02, 2012 11:43 PM
>> To: North American Networking and Offtopic Gripes List
>> Subject: Internet routing table "completeness" monitoring?
>>
>> Has anyone put in place a method to identify if one their BGP peers
suddenly withdraws X% of their prefixes?
>>
>> e.g I should expect ~420k prefixes in a "complete"[1] routing table
from a transit peer today. If suddenly I'm only getting 390k prefixes
I'd guess a major network was depeered or similiar.
>>
>> If so how are people doing this? SNMP MIB, screen scrape?
>>
>>
>>
>> [1] Varying levels of completeless apply.
>>
>>
>>
>
> wfms
>
>
So, there is something called the BGP Monitoring Protocol (BMP):
http://tools.ietf.org/html/draft-ietf-grow-bmp-06
http://www.nanog.org/meetings/nanog45/abstracts.php?pt=MTM2NiZuYW5vZzQ1&nm=nanog45

Looks like it is supported in JunOS.

Has anyone used it?  If so, what monitoring software are you using?


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
 
iQEcBAEBAgAGBQJQbFsYAAoJEBxhAh+LWUKi/WwIAKxVmcCfI6xng0lAL5UxHSGK
v+fp5Q1d40hCu1aWWeeV/eYvyOEZSwkY/jSK0EaVrdmv0y4GQttQqSfGk+1RQOK/
jZAD/r0Fd9K9vMLJ5Te+bkjYuOp23G2bDn8QWuls4HBc1nHxkPc6arzUTgTzEFAZ
+Ljk3MQSHiZ+nb6fkX+Yb7e3UJZjpkuWaNeqGcKz9FR9PJT5UZI8Yf2iwMHtVl/l
R9XfAIG/xDd64oKEDbt8JmtQkqS64ZnCFe+B/yEuTKC6Pl0DUm4orH7322oxjxOW
yDloqmhO5pCmVETFHwn0ocTpDKqG2zE4zA4bHL+w+xePSS61DpUf51V3eg8JgZo=
=Ofld
-END PGP SIGNATURE-

Re: Internet routing table "completeness" monitoring?

[Christopher Morrow]

On Wed, Oct 3, 2012 at 9:55 AM, Eric Tykwinski  wrote:
> I agree, and just use the Threshold plugin so when it drops below or goes
> above a certain # to notify you.
> http://docs.cacti.net/plugin:thold

is a threshold helpful here? (well, it's helpful to a point at least)
what if your neighbour starts deaggragating (or sending you their
internal deaggragates) in place of 50k real routes? no alarm, no
'change' from a numbers perspective, but certainly a traffic shift and
reach-ability change :(

Isn't a speed-of-change threshold also interesting here?

RE: [j-nsp] Krt queue issues

[Jensen Tyler]

Look into Static route retain. Should keep the route in the forwarding table.

>From Jniper site
<<<
Route Retention

By default, static routes are not retained in the forwarding table when the 
routing process shuts down. When the routing process starts up again, any 
routes configured as static routes must be added to the forwarding table again. 
To avoid this latency, routes can be flagged as retain, so that they are kept 
in the forwarding table even after the routing process shuts down. Retention 
ensures that the routes are always in the forwarding table, even immediately 
after a system reboot.
>>>

Thanks,

Jensen Tyler
Sr Engineering Manager
Fiberutilities Group, LLC


-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Benny Amorsen
Sent: Wednesday, October 03, 2012 8:32 AM
To: Jared Mauch
Cc: Saku Ytti; juniper-...@puck.nether.net
Subject: Re: [j-nsp] Krt queue issues

Jared Mauch  writes:

> As far as the fallback 'default' route, if you are purchasing transit 
> from someone, you could consider a last-resort default pointed at 
> them. You can exclude routes like 10/8 etc by routing these to discard
> + install on your devices.

That only helps if the default gets installed first, though. If the default has 
to wait at boot in the krt-queue behind the 300k+ Internet-routes, I have not 
really gained anything...

I suppose it is likely that a static default would be installed before the BGP 
sessions even come up.


/Benny
___
juniper-nsp mailing list juniper-...@puck.nether.net 
https://puck.nether.net/mailman/listinfo/juniper-nsp

RE: So what's the deal with 10Gbase-T

[Jima]

 Odd wording on the timing; I'm aware of at least one manufactured 1U
system with onboard SFP+ that's been available since Q1-Q2 of this year.

 (I don't work for the manufacturer, just for a fairly happy customer.)

 Jima

On Wed, Oct 3, 2012, at 7:54am, Drew Weaver wrote:
> It was really unfortunate of Intel to release Romley with 10G copper only
> support at launch, I hear though that soon there will be motherboards with
> the SFP+ ports integrated.
>
> -Original Message-
> From: Miquel van Smoorenburg [mailto:mik...@xs4all.net]
> Sent: Monday, October 01, 2012 5:28 PM
> To: andr...@livejournalinc.com
> Cc: nanog@nanog.org
> Subject: Re: So what's the deal with 10Gbase-T
>
> In article
> ,
> Andreas Echavez   wrote:
>>Does anyone here have experience running copper 10Gbase-T networks? It
>>seems like the standard just died out.
>
> Well, our new supermicro servers come with 10Gbase-T standard on the
> motherboard.
>
>>For us it would make a lot of sense
>>for our applications -- even if throughput and latency aren't as great.
>>If anyone out there knows of any *copper* 10 gig-t switches (48 port?)
>
> Arista, http://www.aristanetworks.com/
>
> Mike.
>
>
>

RE: Internet routing table "completeness" monitoring?

[William F. Maton Sotomayor]

On Wed, 3 Oct 2012, Joseph Jackson wrote:


I have cacti graph the amount of prefixes announced and withdrawn from a BGP 
peer on each BGP router.


+1

Note that not all router OSs support fetching data like that via SNMP.

We use a custom built thing internally that does this two, which we then 
tack on an alert threshold for.  So if a downstream peer sends us less 
than that, we get an alert.  Handy for those times when they call and ask 
us what we did to their network. :-)


Prior to that, we had a script which whould login, munge the 'show ip bgp 
summary' table output, figure out the deltas and graph or report as 
needed on a particularly troublesome peer.






-Original Message-
From: ML [mailto:m...@kenweb.org]
Sent: Tuesday, October 02, 2012 11:43 PM
To: North American Networking and Offtopic Gripes List
Subject: Internet routing table "completeness" monitoring?

Has anyone put in place a method to identify if one their BGP peers suddenly 
withdraws X% of their prefixes?

e.g I should expect ~420k prefixes in a "complete"[1] routing table from a 
transit peer today.  If suddenly I'm only getting 390k prefixes I'd guess a major network 
was depeered or similiar.

If so how are people doing this? SNMP MIB, screen scrape?



[1] Varying levels of completeless apply.





wfms

RE: Internet routing table "completeness" monitoring?

[Joseph Jackson]

Not sure I don't have any non-cisco BGP routers.  Sorry!



-Original Message-
From: Neil Robst [mailto:neil.ro...@kit-digital.com] 
Sent: Wednesday, October 03, 2012 8:54 AM
To: Joseph Jackson; m...@kenweb.org; North American Networking and Offtopic 
Gripes List
Subject: RE: Internet routing table "completeness" monitoring?

This is still only possible on Cisco routers, isn't it - Foundry/Brocade gear 
doesn't currently include an SNMP OID for this info, does it?

-Original Message-
From: Joseph Jackson [mailto:jjack...@aninetworks.net] 
Sent: 03 October 2012 14:51
To: m...@kenweb.org; North American Networking and Offtopic Gripes List
Subject: RE: Internet routing table "completeness" monitoring?

I have cacti graph the amount of prefixes announced and withdrawn from a BGP 
peer on each BGP router.



-Original Message-
From: ML [mailto:m...@kenweb.org] 
Sent: Tuesday, October 02, 2012 11:43 PM
To: North American Networking and Offtopic Gripes List
Subject: Internet routing table "completeness" monitoring?

Has anyone put in place a method to identify if one their BGP peers suddenly 
withdraws X% of their prefixes?

e.g I should expect ~420k prefixes in a "complete"[1] routing table from a 
transit peer today.  If suddenly I'm only getting 390k prefixes I'd guess a 
major network was depeered or similiar.

If so how are people doing this? SNMP MIB, screen scrape?



[1] Varying levels of completeless apply.

RE: Internet routing table "completeness" monitoring?

[Eric Tykwinski]

I agree, and just use the Threshold plugin so when it drops below or goes
above a certain # to notify you.
http://docs.cacti.net/plugin:thold


-Original Message-
From: Joseph Jackson [mailto:jjack...@aninetworks.net] 
Sent: Wednesday, October 03, 2012 9:51 AM
To: m...@kenweb.org; North American Networking and Offtopic Gripes List
Subject: RE: Internet routing table "completeness" monitoring?

I have cacti graph the amount of prefixes announced and withdrawn from a BGP
peer on each BGP router.

RE: So what's the deal with 10Gbase-T

[Drew Weaver]

It was really unfortunate of Intel to release Romley with 10G copper only 
support at launch, I hear though that soon there will be motherboards with the 
SFP+ ports integrated.

-Original Message-
From: Miquel van Smoorenburg [mailto:mik...@xs4all.net] 
Sent: Monday, October 01, 2012 5:28 PM
To: andr...@livejournalinc.com
Cc: nanog@nanog.org
Subject: Re: So what's the deal with 10Gbase-T

In article ,
Andreas Echavez   wrote:
>Does anyone here have experience running copper 10Gbase-T networks? It 
>seems like the standard just died out.

Well, our new supermicro servers come with 10Gbase-T standard on the 
motherboard.

>For us it would make a lot of sense
>for our applications -- even if throughput and latency aren't as great. 
>If anyone out there knows of any *copper* 10 gig-t switches (48 port?)

Arista, http://www.aristanetworks.com/

Mike.

RE: Internet routing table "completeness" monitoring?

[Joseph Jackson]

I have cacti graph the amount of prefixes announced and withdrawn from a BGP 
peer on each BGP router.



-Original Message-
From: ML [mailto:m...@kenweb.org] 
Sent: Tuesday, October 02, 2012 11:43 PM
To: North American Networking and Offtopic Gripes List
Subject: Internet routing table "completeness" monitoring?

Has anyone put in place a method to identify if one their BGP peers suddenly 
withdraws X% of their prefixes?

e.g I should expect ~420k prefixes in a "complete"[1] routing table from a 
transit peer today.  If suddenly I'm only getting 390k prefixes I'd guess a 
major network was depeered or similiar.

If so how are people doing this? SNMP MIB, screen scrape?



[1] Varying levels of completeless apply.

Re: Internet routing table "completeness" monitoring?

[Jay Ashworth]

- Original Message -
> From: "ML" 

> Has anyone put in place a method to identify if one their BGP peers
> suddenly withdraws X% of their prefixes?
> 
> e.g I should expect ~420k prefixes in a "complete"[1] routing table from
> a transit peer today. If suddenly I'm only getting 390k prefixes I'd
> guess a major network was depeered or similiar.
> 
> If so how are people doing this? SNMP MIB, screen scrape?

Well, if I had to do it, I think I'd just point munin at the router, yes,
using SNMP, and put the prefix count graph up on the Big Wall, as a filled 
curve.  That thing jumps around, someone will likely notice.

This assumes a staffed NOC, of course, but it still gives you something to
look at historically if you note a problem in an unstaffed situation as well.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274

Re: RFC becomes Visio

[Michael Hallgren]

Le mercredi 03 octobre 2012 à 07:31 -0400, Rodrick Brown a écrit :
> On Oct 3, 2012, at 7:26 AM, Brian Christopher Raaen
>  wrote:
> 
> 
> > The newest version of libreoffice draw can open Visio diagrams.
> > 
> > 
> 
> 
> Also Microsoft does provide a free Visio plugin/viewer for Internet
> Explorer. 
> 
> 
> http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=21701
> 


Can you also edit/write using these?

mh

> > ---
> > Brian Raaen
> > Zcorum
> > 
> > On Tue, Oct 2, 2012 at 5:43 PM, Michael Hallgren
> >  wrote:
> > > Le mardi 02 octobre 2012 à 23:25 +0200, Dan Luedtke a écrit :
> > > > On Fri, 2012-09-28 at 19:31 +0100, Nick Hilliard wrote:
> > > > > Here's a visio diagram you can send them:
> > > > > 
> > > > > http://www.foobar.org/~nick/bgp-network-diagram.vsd
> > > > 
> > > > Is there a .png version of it somewhere?
> > > > The whole thread made my day, I'm eager to see this diagram as
> > > > well.
> > > > I don't have this MS Visio thingy you all use to set up your
> > > > Avian
> > > > Carrier BGP sessions...
> > > 
> > > Don't use ``MS Visio thingy'', prefer TeX with metapost, PGF/TikZ
> > > (or
> > > PSTRicks). The output is by far more beautiful, and maintaining
> > > the
> > > document much more slim.
> > > 
> > > Cheers,
> > > mh
> > > 
> > > > 
> > > > Regards
> > > > 
> > > > Dan
> > > > 
> > > 
> > > 
> > > 
> > 
> > 

Re: RFC becomes Visio

[Rodrick Brown]

On Oct 3, 2012, at 7:26 AM, Brian Christopher Raaen <
mailing-li...@brianraaen.com> wrote:

The newest version of libreoffice draw can open Visio diagrams.


Also Microsoft does provide a free Visio plugin/viewer for Internet
Explorer.

http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=21701

---
Brian Raaen
Zcorum

On Tue, Oct 2, 2012 at 5:43 PM, Michael Hallgren  wrote:

Le mardi 02 octobre 2012 à 23:25 +0200, Dan Luedtke a écrit :

On Fri, 2012-09-28 at 19:31 +0100, Nick Hilliard wrote:

Here's a visio diagram you can send them:


http://www.foobar.org/~nick/bgp-network-diagram.vsd


Is there a .png version of it somewhere?

The whole thread made my day, I'm eager to see this diagram as well.

I don't have this MS Visio thingy you all use to set up your Avian

Carrier BGP sessions...


Don't use ``MS Visio thingy'', prefer TeX with metapost, PGF/TikZ (or

PSTRicks). The output is by far more beautiful, and maintaining the

document much more slim.


Cheers,

mh



Regards


Dan

Re: RFC becomes Visio

[Brian Christopher Raaen]

The newest version of libreoffice draw can open Visio diagrams.

---
Brian Raaen
Zcorum

On Tue, Oct 2, 2012 at 5:43 PM, Michael Hallgren  wrote:
> Le mardi 02 octobre 2012 à 23:25 +0200, Dan Luedtke a écrit :
>> On Fri, 2012-09-28 at 19:31 +0100, Nick Hilliard wrote:
>> > Here's a visio diagram you can send them:
>> >
>> > http://www.foobar.org/~nick/bgp-network-diagram.vsd
>>
>> Is there a .png version of it somewhere?
>> The whole thread made my day, I'm eager to see this diagram as well.
>> I don't have this MS Visio thingy you all use to set up your Avian
>> Carrier BGP sessions...
>
> Don't use ``MS Visio thingy'', prefer TeX with metapost, PGF/TikZ (or
> PSTRicks). The output is by far more beautiful, and maintaining the
> document much more slim.
>
> Cheers,
> mh
>
>>
>> Regards
>>
>> Dan
>>
>
>
>