Re: is ipv6 fast, was silly Redeploying

[John Lee]

Cisco and Juniper routers have had v6 functionality for over 10 years.
Lucent/Nokia, and others. Check UNL list at
https://www.iol.unh.edu/registry/usgv6 for v6 compliant routers and
switches.

John Lee

On Fri, Nov 19, 2021 at 5:48 PM John Levine  wrote:

> It appears that Michael Thomas  said:
> >And just as impossible since it would pop it out of the fast path. Does
> >big iron support ipv6 these days?
>
> My research associate Ms. Google advises me that Juniper does:
>
>
> https://www.juniper.net/documentation/us/en/software/junos/routing-overview/topics/concept/ipv6-technology-overview.html
>
> As does Cisco:
>
>
> https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-9600-series-switches/nb-06-cat9600-ser-sup-eng-data-sheet-cte-en.pdf
>
> R's,
> John
>

Re: facebook outage

[John Lee]

I was seeing NXDOMAIN errors, so I wonder if they had a DNS outage of some
sort??

On Mon, Oct 4, 2021 at 5:14 PM Bill Woodcock  wrote:

> They’re starting to pick themselves back up off the floor in the last two
> or three minutes.  A few answers getting out.  I imagine it’ll take a while
> before things stabilize, though.
>
> -Bill
>
>

Re: DoD IP Space

[John Lee]

It is the DISA DOD NIC at:

https://disa.mil/About/Contact

Which will give you the DISA help desk phone number.

John Lee

On Mon, Nov 4, 2019 at 3:57 AM Chris Knipe  wrote:

> Hi Guys,
>
> Except for the email on ARIN's details, does anyone else have a contact
> for the DoD?
>
> We are experiencing a situation with a 3rd party (direct peer), wanting to
> advertise DoD address space to us, and we need to confirm whether they are
> allowed to do so or not.
>
> Range in question is the 22.0.0.0/8 network, which according to ARIN is
> actively assigned to the DoD (US).
>
> --
>
> Regards,
> Chris Knipe
>

Re: Has virtualization become obsolete in 5G?

[John Lee]

The short answer is that the "Cloud Native Computing" folks need to talk to
the Intel Embedded Systems Application engineers to discover that micro
services have been running on Intel hardware in (non-standard) containers
for years. We call it real time computing, process control,... Current
multi Terabit Ethernet interfaces require specialized hardware and
interfaces that will connect fiber optics to clouds but cannot be run on
clouds.

Some comments on Software Controlled Telecomm (/datacom) networking. When
DTMF was invented the telco used in band signaling for call control. Kevin
Mitnick et. al. designed red and black boxes to control the telco systems
so the telcos moved call control out of band. They created SIgnal Control
Points which managed the actual circuit switch hardware to route calls or
eventually 64kbps digital paths and this protocol was SS#7. There were six
to seven volumes of CLASS services that were enabled by SS#7 which ran on
UNIX systems developed by Bell Labs. In the mid seventies, I worked on VM
systems from DEC and Apollo of which Apollo had the better virtualization
that worked across the network and was the first "cloud" system that I
worked on.

In the mid nineties, I had worked on large Gigabit/Terabit routers but
again the control plane was part of the data plane until ATM based
networks  could use out of band control to setup a SVC between input port
and output port and switch the IP packets instead of routing them achieving
network end to end delays of less than milliseconds. VLAN and MPLS
protocols were developed to switch packets in the backbone of the networks
and not to route them.

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.

Embedded systems have implemented "micro services" for years as that is how
you handle interrupt driven real time control. We call this a context
switch which is still hardware CPU dependent. As far as I know, current
standard containers do not handle real time CPU interrupts or do they allow
very tight timing reponse loops within the standard containers?

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.) :)

On Sat, Aug 1, 2020 at 8:35 AM Mark Tinka  wrote:

>
>
> On 1/Aug/20 11:23, Etienne-Victor Depasquale wrote:
>
> Over the past few weeks, I've attended webinars and watched videos
> organized by Intel.
> These activities have centred on 5G and examined applications (like
> "visual cloud" and "gaming"),
> as well as segment-oriented aspects (like edge networks, 5G RAN and 5G
> Core).
>
> I am stunned (no hyperbole) by the emphasis on Kubernetes in particular,
> and cloud-native computing in general.
> Equally stunning (for me), public telecommunications networks have been
> portrayed
> as having a history that moved from integrated software and hardware,
> to virtualization and now to cloud-native computing.
> See, for example Alex Quach, here
> 
>  @10:30).
> I reason that Intel's implication is that virtualization is becoming
> obsolete.
>
> Would anyone care to let me know his thoughts on this prediction?
>
>
> In the early dawn of SDN, where it was cool to have the RP's in Beirut and
> the line cards in Lagos, the industry quickly realized that was not
> entirely feasible.
>
> If you are looking at over-the-top services, so-called cloud-native
> computing makes sense in order to deliver that value accordingly, and with
> agility. But as it pertains to actual network transport, I'm not yet sure
> the industry is at the stage where we are confident enough to decompose
> packet forwarding through a cloud.
>
> Network operators are more likely to keep using kit that integrates
> forwarding hardware as well as a NOS, as no amount of cloud architecting is
> going to rival a 100Gbps purpose-built port, for example.
>
> Suffice it to say, there was a time when folk were considering running
> their critical infrastructure (such as your route reflectors) in AWS or
> similar. I'm not quite sure public clouds are at that level of confidence
> yet. So if some kind of cloud-native infrastructure is to be considered for
> critical infrastructure, I highly suspect it will be 

Re: Should ISP block child pornography?

[John Lee]

It is my understanding that ISPs block IP addresses and domains under court
order now for copyright violations, criminal activity which would include
CP. They require a court order as they cannot ascertain if it is CP or not,
that is a Law Enforcement decision. The US Supreme Court decision's was
just being nude is not lewd, also with aging software which can regress
photos, LEOs in the US have to ascertain if this is CP or photo shopped.

On Tue, Dec 11, 2018 at 12:54 PM Max Tulyev  wrote:

> ...and you will see the TOR exit nodes instead of crime home IP if
> censorship is implemented.
>
> 11.12.18 19:35, Aaron1 пише:
> > ... The only thing I can think of is the idea that I’ve heard before is
> > the way to catch someone is to watch them well they are accessing, the
> > concept of honeypots comes to mind
> >
> > Aaron
> >
> > On Dec 11, 2018, at 10:43 AM, Larry Allen  > > wrote:
> >
> >> I can't imagine a single rational argument against this.
> >>
> >> On Tue, Dec 11, 2018, 10:56 William Anderson  >>  wrote:
> >>
> >> On Fri, 7 Dec 2018 at 06:08, Lotia, Pratik M
> >> mailto:pratik.lo...@charter.com>> wrote:
> >>
> >> Hello all, was curious to know the community’s opinion on
> >> whether an ISP should block domains hosting CPE (child
> >> pornography exploitation) content? Interpol has a ‘worst-of’
> >> list which contains such domains and it wants ISPs to block it.
> >>
> >>
> >> This already happens in the UK, and has done for years.
> >>
> >> https://en.wikipedia.org/wiki/Child_abuse_image_content_list
> >>
> >>
> >> -n
> >>
>

Re: Buying IPv4 blocks

[John Lee]

If is a new US business and you are working internationally why not go
simple and use IPv6 addresses?

John Lee

On Thu, Oct 4, 2018 at 10:59 AM Ross Tajvar  wrote:

> Thanks everyone who replied. I got many responses off-list, including a
> lot of positive endorsements for several different vendors. It's good to
> know there are so many reputable options.
>
> -Ross
>
> On Mon, Oct 1, 2018 at 9:57 PM, Ross Tajvar  wrote:
>
>> Hi all,
>>
>> My US-based employer will be starting a new business unit soon that will
>> require IPv4 addresses (aiming for a /22 to start with). I know ARIN has a
>> waitlist (though I'm not sure where they're getting new IPs from), but the
>> faster way is to buy blocks from people who already have them. I'm aware of
>> Hilco Streambank - are there any other auctions? If I want to buy via
>> private sale, does anyone know of ways to find sellers?
>>
>> Thanks,
>> Ross
>>
>
>

Re: Had an idea - looking for a math buff to tell me if it's possible with today's technology.

[John Lee]

The concept is called fractals where you can compress the image and send the
values and recreate the image. There was a body of work on the subject, I
would say in the mid to late eighties where two Georgia Tech professors
started a company doing it.

John (ISDN) Lee

On Wed, May 18, 2011 at 4:07 PM, Landon Stewart lstew...@superb.net wrote:

 Lets say you had a file that was 1,000,000,000 characters consisting of
 8,000,000,000bits.  What if instead of transferring that file through the
 interwebs you transmitted a mathematical equation to tell a computer on the
 other end how to *construct* that file.  First you'd feed the file into a
 cruncher of some type to reduce the pattern of 8,000,000,000 bits into an
 equation somehow.  Sure this would take time, I realize that.  The equation
 would then be transmitted to the other computer where it would use its
 mad-math-skillz to *figure out the answer* which would theoretically be the
 same pattern of bits.  Thus the same file would emerge on the other end.

 The real question here is how long would it take for a regular computer to
 do this kind of math?

 Just a weird idea I had.  If it's a good idea then please consider this
 intellectual property.  LOL


 --
 Landon Stewart lstew...@superb.net
 SuperbHosting.Net by Superb Internet Corp.
 Toll Free (US/Canada): 888-354-6128 x 4199
 Direct: 206-438-5879
 Web hosting and more Ahead of the Rest: http://www.superbhosting.net

RE: off-topic: summary on Internet traffic growth History

[John Lee]

Andrew,

Earlier this week I had a meeting with the ex-Director of the Network 
Operations Center for MFS-Datanet/MCI whose tenure was through 1999. From 1994 
to 1998 they were re-architeching the Frame Relay and ATM networks to handle 
the growth in traffic including these new facilities called peering points of 
MAE-East and MAE-West. From roughly 1990 to then end of 1996 they saw traffic 
on their switches grow at 50-70% growth every 6 months. By the last half of 
1996 there was a head of line blocking problem on the DEC FDDI switches that 
was regularly bringing down the Internet. The architecture had lower traffic 
circuits were going through concentrators while higher traffic circuits were 
directly attached to ports on the switchs.



MFS-Datanet was not going to take the hit for the interruptions to the Internet 
and was going to inform the trade press there was a problem with DEC FDDI 
switches so Digital gave six switches for the re-architecture of the MAEs to 
solve the problem. Once this problem was solved the first quarter of 1997 saw a 
70% jump in traffic that quarter alone. This historical event would in my 
memory be the genesis of the 100% traffic growth in 100 days legend. (So it was 
only 70% in 90 days which for the marketing folks does not cut it so 100% in 
100 days sounds much better?? :) )



MCI bought MFS-Datanet because MCI had the customers and MFS-Datanet had all of 
the fiber running to key locations at the time and could drastically cut MCI's 
costs. UUNET merged with MCI and their traffic was put on this same network. 
MCI went belly up and Verizon bought the network.



Personal Note: from 1983 to 90 I worked for Hayes the modem folks and became 
the Godfather to Ascend communications with Jeanette, Rob, Jay and Steve whose 
team produced the TNT line of modem/ISDN to Ethernet central site concentrators 
(in the early ninties) that drove a large portion of the user traffic to the 
Internet at the time, generating the bubble.



John (ISDN) Lee

From: Andrew Odlyzko [odly...@umn.edu]
Sent: Wednesday, August 11, 2010 12:55 PM
To: nanog@nanog.org
Subject: off-topic: summary on Internet traffic growth myths

Since several members of this list requested it, here is a summary
of the responses to my request for information about Internet growth
during the telecom bubble, in particular the perceptions of the
O'Dell/Sidgmore/WorldCom/UUNet Internet doubling every 100 days
myth.

First of all, many thanks to all those who responded, on and off-list.
This involved extensive correspondence and some long phone conversations,
and helped fill out the picture of those very confusing times (and
also made it even clearer than before that there were many different
perspectives on what was happening).

The entire message is rather long, but it is written in sections,
to make it easy to get the gist quickly and neglect the rest.

Andrew


---

1.  Short summary: People who got into the game late, or had been
working at small ISPs or other enterprises, were generally willing
to give serious credence to the Internet doubling every 100 days
tale.  The old-timers, especially those who worked for large ISPs
or other large corporate establishment or research networks, were
convinced by the late 1990s that this tale was false, but did not
talk about it publicly, even inside the NANOG community.

---

2.  Longer version: The range of views was very wide, and hard to
give justice to in full.  But there seemed to be two distinct
groups, and the consensus views (which obviously exclude quite
a few people) appear to have been:

2A: Those who entered the field in the late 1990s, especially
if they worked for small ISPs or other small enterprises, tended
to regard the claim seriously.  (But it should be remarked that
hardly anybody devoted too much effort or thought to the claim,
they were too busy putting out fires in their own backyards to
worry about global issues.)  They remembered periods of desperate
efforts to keep up with exploding demand in their businesses.
We saw just a few hours ago a post about LINX growing 5.5x in
one year.  Somebody else wrote about growing their business's
traffic 1,000x in 2 years, or about 30x per year.  People involved
in such incidents often tended to think that their experience
during such times might not have been untypical.

2B: Those who worked at places with large traffic, and especially
those who got into the field in the early 1990s, were quite sure
by the late 1990s that the UUNet fable was just that.  Comments
regarding everything emanating from UUNet during that period
included phrases like blowing smoke, rolling our eyes, taking
it with a rock of salt.  They had no direct knowledge of what
went on inside UUNet, but from watching peering traffic, talking
to salespeople about customer losses and 

RE: Partial Use Of one Regions IP Block in another

[John Lee]

Some pseudo random thoughts and questions? (my BGP is rusty.)

1. Does it violate your AUP with APNIC?

2. If the larger routing prefix is from APNIC will your upstream in the EMEA 
region filter or black hole the sub prefix since it is from APNIC and not RIPE 
and would appear to be a hijacked block? (In my experience in some European 
countries rules are more strictly enforced than in other areas of the globe. 
I will spare you the American, Russian and French standards organization joke.)

3. It would appear that again since it is in an APNIC sub-prefix would you need 
to carry the packets from a PoP in APNIC region to your facility in the EMEA 
assuming the sub prefix is not large enough to be propagated in normal BPG 
updates?

4. And if the bits did get through for a period of time would the transit 
provider determine that they did not want to carry them any more and add 
filtering at any random point in time?

These questions assume that you do not have a single transit provider that 
covers both of your locations in the two different regions and can custom 
route the packets.

John (ISDN) Lee

From: Net [funky...@gmail.com]
Sent: Thursday, May 20, 2010 8:06 AM
To: nanog@nanog.org
Subject: Partial Use Of one Regions IP Block in another

Hi folks,

Are there any policies set by internet registries and/or transit
providers today that prohibits organizations from using a Partially
used IP Block allocated in one region say AP through APNIC to be
comissioned and Propagated in another region such as EMEA serviced by
RIPE?.

Obv, the best approach would be to acquire a new Block in the 2nd
region through its own registry, but sometimes due to strict
prvisioning timelines, legal delays in getting the necessary approvals
involved etc make this option less attractive. From an IPV4 space
depletion perspective as well, it might be feasible if organizations
having a large block in one region could split it amongst multiple
regions to prevent Wastage.

Any thoughts/expereinces and feedback would be appreciated.

Regards,

--
Sent from my mobile device

RE: Why choose 120 volts? When DC will do

[John Lee]

What is all this talk about AC. Real data centers use DC. 

John (ISDN) Lee

From: Seth Mattinen [se...@rollernet.us]
Sent: Tuesday, May 26, 2009 3:39 PM
To: nanog@nanog.org
Subject: Why choose 120 volts?

I have a pure curiosity question for the NANOG crowd here. If you run
your facility/datacenter/cage/rack on 120 volts, why?

I've been running my facility at 208 for years because I can get away
with lower amperage circuits. I'm curious about the reasons for using
high-amp 120 volt circuits to drive racks of equipment instead of
low-amp 208 or 240 volt circuits.

~Seth

RE: Looking for someone to bounce some Fore questions off of

[John Lee]

Jason,

Fore was purchased by Marconi who sold me the Fore ASX switches for a broadband 
access network in 2001. Ericsson still seems to be selling ASX and TNX boxes. 
Do you have access to an ATM protocol anlyzers with the port type and speeds 
you are running?

John (ISDN) Lee


From: Jason Lixfeld [ja...@lixfeld.ca]
Sent: Thursday, February 12, 2009 5:08 PM
To: NANOG
Subject: Looking for someone to bounce some Fore questions off of

My google ninja foo seems to suck as I'm coming up empty looking for a
forum or mailing list for Fore ATM related stuff.  I'm pretty green to
the Fore ASX line, and I'm in a position at the moment where I need to
try to figure out why something seems to be misbehaving.  Not sure if
it's me or the provider or what, so if someone with some experience
with this type of gear has a few cycles and can ping me off list, I'd
appreciate it.

RE: IPv6 delivery model to end customers

[John Lee]

Michael,

From my work in access networks they are:

IPv6 native support for:

Routed Access - Ethernet or Wireless, global prefix under the main or dot1Q isl 
encapsulated sub-interfaces. 
For DSL and ATM PVCs routed RFC 2684 encapsulation with a different IPv6 prefix 
for each one of the PVCs.

Bridged Access - RFC 2684 where the user traffic reaches the access router over 
a bridged PVC.

PPP-Encapsulated IPv6 - PPPoA/IPv4 access was my favorite in the early days and 
finally moving in about 2004 or so to PPPoE (RFC 2516). Most DSL and Layer 2 
providers that I used had PPPoA in their access network and then handed off to 
me as an ATM PVC with L2TP encapsulated user streams. PPPoE/PPPoA support both 
IPv4 and IPv6 packets natively.

SP can leverage their existing IPv4 access infrastructure by utilizing IPv6 
over L2TPv2 or in deploying IPv6 natively to the CPE by utilizing L2TPv3.

My IPv4 only deployment in 2001 used DSLAMs that had limited number of active 
CPEs and DS3/T3 upstreams to the network. We used front end Fore/Marconi ATM 
switches in front of Redback aggregation switches connecting to Cisco 6509s and 
then GSR 12012s as the backbone routers. The Redback authenticated with RADIUS 
servers using CHAP.

The DSLAMs were upgrade over the next two to three years for larger number of 
CPE tributaries and optical (OC-3c and OC-12c) network uplinks. In my advancing 
years if memory serves in 2005/2006 timeframe (in the US) the CPE, DSLAMS, 
aggregation and other switches and routers supported IPv6.

Now you have both second and third generation support for IPv6 in these devices 
(Cisco, Juniper, et al) and rumor has it that Linksys and Netgear have IPv6 
plans in their roadmaps or devices in their labs.

For PD and DHCPv6 there are other tools that allow much more control over IP 
address assignment and lifecycle control that I will not discuss here.

I am not slighting Cable here, I do not have the first hand experience with 
cable supporting IPv6.

IMHO rolling out IPv6 to the customer is a business decision now not a 
technical one.

John (ISDN) Lee


From: Mikael Abrahamsson [swm...@swm.pp.se]
Sent: Saturday, February 07, 2009 2:45 AM
To: nanog@nanog.org
Subject: IPv6 delivery model to end customers

I didn't know where to jump in in the current discussion and what I wanted
to discuss was quite general, so I thought I'd create a new thread
instead.

So, anyone saying IPv6 is ready for prime-time whereever IPv4 is used, has
a very simplified view of the world. Yes, IPv6 works in the classic routed
network model where everything is statically set up (often manually), for
example with an ISP run CPE and static/dynamic routing and a fixed /48
issued for that customer and SWIPed. Then it's easy to delegate
reverse-DNS etc to the customer DNS.

Now, take for instance the residential LAN case. There are several models
on how to do this, but they all (that I know of) reside around the fact
that each customer gets one or more globally routed IP address via DHCP,
and security against spoofing and man in the middle-attacks is either
done via forced-forwarding in the L2 device the customer connects to, or
it's done via setting L3 accesslists learnt via DHCP snooping that inspect
L2-packets in that same device. Often both is done, and also things like
ARP inspection, rogue dhcp server protection, MAC-rewrite etc is used.
These are essential security mechanisms because customers should be
protected from each other when it comes to these types of L2 attacks.
Tracability (who had what IP at what time) is done via DHCP option82 and
logging of this information. So, the L2 devices closest to the customer
does a lot of magic. All of these mechanisms were developed in the first
half of the last decade.

Now, with IPv6 this model changes drastically. The proposed mechanisms for
IP number handout etc, is RA and DHCPv6. How does that fit into the model
above? It doesn't, and the L2 devices surely won't sniff it and enforce
security measures mentioned above.

My ideal model would be to replace the above mentioned L2 device with a
small and simple L3 device (L3 switch) with very small TCAM (TCAM size 6-8
times port number should be enough), where this device uses link-local
with the CPEs (would require all customers to actually have a router at
home), hands out prefixes via DHCPv6-PD, inserts route towards customer
link-local address, provisions anti-spoofing ACLs on that port, logs what
prefix was given out to each port at what time, and off we go. (Rationale
for link-local only is to have only customer devices in Customer IP
space and only ISP infrastructure in that IP-space. This is equivalent to
ip unnumbered in IPv4 in my view.) I have pitched this idea in the IETF
v6ops list and it's now included in a draft that lists different models of
IPv6 delivery.

As far as I know, this IPv6 L3 device doesn't exist (in the pricerange
needed for massive residential roll-out anyhow).

RE: IPv6 delivery model to end customers

[John Lee]

Yes it was definitely last century. With your 30 USD per port and no tunnels 
poses some interesting challenges. Customer CPE tunnel access was the main 
method discussed in the different v6 meetings I attended. I appreciate you 
bringing up this set of requirements since it needs to be addressed for fuller 
deployment of IPv6 to residential customers.

John


From: Mikael Abrahamsson [swm...@swm.pp.se]
Sent: Saturday, February 07, 2009 1:12 PM
To: John Lee
Cc: nanog@nanog.org
Subject: RE: IPv6 delivery model to end customers

On Sat, 7 Feb 2009, John Lee wrote:

 My IPv4 only deployment in 2001 used DSLAMs that had limited number of
 active CPEs and DS3/T3 upstreams to the network. We used front end
 Fore/Marconi ATM switches in front of Redback aggregation switches
 connecting to Cisco 6509s and then GSR 12012s as the backbone routers.
 The Redback authenticated with RADIUS servers using CHAP.

My ADSL2+ design I did in 2002-03 or so, used one vlan per customer in the
DSLAM (first version was 1U 24 port ADSL L2 ethernet DSLAM, second
generation was chassis based ADSL2+ DSLAM did 1024 vlans and had ~800
ADSL2+ ports), vlans aggregated with an L3 switch doing GigE with the
DSLAM, and one IP address per vlan (L3 switch was RFC3069 capable), no
DHCP just statically provisioned when doing customer delivery. Worked
great. Quite cheap as well. DSLAM was basically a L2 PVC-VLAN and PHY
media converter.

But I wasn't talking (A)DSL. DSL is last century. I am talking VDSL2/ETTH.
Security model there is to only have ethernet and IP, no PPP/ATM, no
L2TPv3 or PPPoE. Let's skip the terms BRAS/LNS etc. Anything that
terminates tunnels is expensive (apart from GRE/IPV6IP which the 7600
seems to do very well, but I don't like tunnels. I like native). Most of
the ETTH ports are 10/10, 100/10 or 100/100 (or even higher speeds) and
100/10 costs ~30 USD a month. L2TPv3/PPPoE is not an option.

So, we have ~500k ports in my 9 million inhabitants country which are done
via L2 switches in basements with CAT5/6 or fiber to the home. They use
the security model I talked about before which I didn't really see a
mention of in the list of IPv6 supported access models you listed. There
are probably many millions more in Asia with the same model.

 IMHO rolling out IPv6 to the customer is a business decision now not a
 technical one.

Well, I want to be able to do IPv6 at close to the same cost and security
as I do IPv4 today. In your BRAS/LNS world it might be easy, but that's
not the world I live in.

--
Mikael Abrahamssonemail: swm...@swm.pp.se

RE: high latency ds3 issue on unloaded line

[John Lee]

Mike,

Your latencies which suddenly appear for several hours and then go away and do 
this on a regular basis  sounds like a layer 2, facility switching issue. As 
you indicated  the problem comes on during the day and then lets up late in 
the evening sounds like the under lying facility is being switched back around 
the long side of the SONET ring or other facility. Some carrier facilities 
are scheduled for one path or direction say during the day that are supposed 
to be for lower latency time periods for interactive work and then switch for a 
lower cost, higher latency path in the evening when computer to computer 
backups do not care. If you can plot the times the issues start and end and 
that these occur daily during the week and not on weekends etc that would be a 
strong indicator.

John (ISDN) Lee


From: mike [EMAIL PROTECTED]
Sent: Friday, September 26, 2008 12:04 PM
To: nanog@nanog.org
Subject: high latency ds3 issue on unloaded line

Hello,

I have a ds3 from qwest which has daily issues with insane
point-to-point latencies sometimes exceeding 1000ms for hours on end,
and which suddenly disappear, and does not appear to correspond with
actual measured link utilization (less than 20mbps most days).

To make a long investigation short, the problem comes on during the
day and then lets up late in the evening. I have tested and examined
everything at the ip layer and no it's not high utilization, an ACL,
router cpu or bad hardware, no line errors or other issues visible from
interface or controller stats. yes I have flushed all hardware, and I
have a 7204vxr/npe-400 with this single ds3. The only clue seems to be
millions of 'output drops' from qwest's side. And at night I can hit
popular ftp mirrors from a directly attached server and observe my
interface reporting about %100 utilization combined with my users and
customers, so yeah it really is a full line rate ds3. And historically
Mrtg always shows around 20mbps or less utilization and it's only
smokeping that goes off, usually in the afternoon when the point to
point latencies between my router and qwest start heading north, and
consistently at that. I also have another in house tool that takes 30
second snapshots of my ds3 interface in order to catch short bursts that
would be smoothed out with mrtg's 5 minute average, but during these
high latency times there aren't any spikes noted. And for added
confusion (or fun!), the latency can start at any utilization level -
I've observed it while we were pulling just 12mbps, and I have not had
it while we were doing 34mbps, only the time of day seems to be the
common factor.

Qwest has not been able to identify the issue, only note that -
yeah, this really is happening when there is otherwise no real load on
the line - and I am certain we have done everything to rule out the ip
layer. They have put in a 'request' to move me to another router, but I
am not hopeful of a resolution that way as the router we're currently on
doesn't appear otherwise to have the problem with any other subscriber.

What I want to know, is it possible that the underlaying atm/sonet
that carries my ds3 from my facility is somehow oversubscribed or
misconfigured? We have an OC12 fiber entrance and this is the only
circuit provisioned on it, and in our small tiny town the only other
user on the ring with us is comcast (according to the att network
engineer who installed this). I don't know enough about atm/sonet to
imagine conditions that would cause the issues I am seeing here , but
every ip layer tool I have only ever tells me there isn't an ip issue
here. I can issue ping from my router directly to the attached qwest
router and get  1000ms and then other times (out of the problem
window), I am getting 4ms.

If anyone has laughs or beers to offer me, send 'em on cuz I could
use both right about now

Mike-

RE: high latency ds3 issue on unloaded line

[John Lee]

Kris,

No disagreement on the sol, the issue is how many oeos the signal is going 
through and how far it is going. When the facilities switched in a previous 
life the latencies usually took a several hundred millisecond jump but not 
seconds. My question / issue is the repeatability and schedule of the 
lengthening delay and what other activity event would correlate with it.

John


From: kris foster [EMAIL PROTECTED]
Sent: Friday, September 26, 2008 3:17 PM
To: John Lee
Cc: mike; nanog@nanog.org
Subject: Re: high latency ds3 issue on unloaded line

John

Even if this is happening, the distance you can travel at 2/3 sol says
there is something else going wrong here (1 sec latency is a very long
time).

Kris

On Sep 26, 2008, at 11:59 AM, John Lee wrote:

 Mike,

 Your latencies which suddenly appear for several hours and then go
 away and do this on a regular basis  sounds like a layer 2, facility
 switching issue. As you indicated  the problem comes on during the
 day and then lets up late in the evening sounds like the under
 lying facility is being switched back around the long side of the
 SONET ring or other facility. Some carrier facilities are scheduled
 for one path or direction say during the day that are supposed to
 be for lower latency time periods for interactive work and then
 switch for a lower cost, higher latency path in the evening when
 computer to computer backups do not care. If you can plot the times
 the issues start and end and that these occur daily during the week
 and not on weekends etc that would be a strong indicator.

 John (ISDN) Lee

 
 From: mike [EMAIL PROTECTED]
 Sent: Friday, September 26, 2008 12:04 PM
 To: nanog@nanog.org
 Subject: high latency ds3 issue on unloaded line

 Hello,

I have a ds3 from qwest which has daily issues with insane
 point-to-point latencies sometimes exceeding 1000ms for hours on end,
 and which suddenly disappear, and does not appear to correspond with
 actual measured link utilization (less than 20mbps most days).

To make a long investigation short, the problem comes on during the
 day and then lets up late in the evening. I have tested and examined
 everything at the ip layer and no it's not high utilization, an ACL,
 router cpu or bad hardware, no line errors or other issues visible
 from
 interface or controller stats. yes I have flushed all hardware, and I
 have a 7204vxr/npe-400 with this single ds3. The only clue seems to be
 millions of 'output drops' from qwest's side. And at night I can hit
 popular ftp mirrors from a directly attached server and observe my
 interface reporting about %100 utilization combined with my users and
 customers, so yeah it really is a full line rate ds3. And historically
 Mrtg always shows around 20mbps or less utilization and it's only
 smokeping that goes off, usually in the afternoon when the point to
 point latencies between my router and qwest start heading north, and
 consistently at that. I also have another in house tool that takes 30
 second snapshots of my ds3 interface in order to catch short bursts
 that
 would be smoothed out with mrtg's 5 minute average, but during these
 high latency times there aren't any spikes noted. And for added
 confusion (or fun!), the latency can start at any utilization level -
 I've observed it while we were pulling just 12mbps, and I have not had
 it while we were doing 34mbps, only the time of day seems to be the
 common factor.

Qwest has not been able to identify the issue, only note that -
 yeah, this really is happening when there is otherwise no real load on
 the line - and I am certain we have done everything to rule out the ip
 layer. They have put in a 'request' to move me to another router,
 but I
 am not hopeful of a resolution that way as the router we're
 currently on
 doesn't appear otherwise to have the problem with any other
 subscriber.

What I want to know, is it possible that the underlaying atm/sonet
 that carries my ds3 from my facility is somehow oversubscribed or
 misconfigured? We have an OC12 fiber entrance and this is the only
 circuit provisioned on it, and in our small tiny town the only other
 user on the ring with us is comcast (according to the att network
 engineer who installed this). I don't know enough about atm/sonet to
 imagine conditions that would cause the issues I am seeing here , but
 every ip layer tool I have only ever tells me there isn't an ip issue
 here. I can issue ping from my router directly to the attached qwest
 router and get  1000ms and then other times (out of the problem
 window), I am getting 4ms.

If anyone has laughs or beers to offer me, send 'em on cuz I could
 use both right about now

 Mike-

RE: 10GE CWDM

[John Lee]

Zed,

If you are looking for optical systems my fav pub is Lightwave at 
http://lw.pennnet.com/. They list DWDM and CWDM systems, lasers, optics, ROADM 
etc. If you have nanog archives go back at least six months to the thread on 
DWDM vs CWDM et al that I was one of the contributors to.

The last comment you make I do not understand since:

1. DWDM systems have many more lasers / wavelengths that are used and most 
metro and WAN providers can supply you a ITU wavelength at the normally obscene 
prices.

2. CWDM systems are usually 4, 8, 16, 24 that are also on ITU wavelengths like 
DWDM systems but with 50 - 100 nm or more spacing so the lasers and optics do 
not have to be so precise as the DWDM optics.

Currently it is my understanding the 10 Gbps signals are carried on 4 x 2.5 
Gbps signals that are compatible with existing CWDM and DWDM equipment. There 
are 40 Gbps DWDM systems and 10 Gbps lasers on 100 Gbps and greater capacity 
systems. I agree with Alex's comments that to have 10 Gbps on a CWDM system is 
to have a CWDM system of at least 40 to 100 Gbps and that is very expensive 
today.

John (ISDN) Lee

From Lightwafve:

Optelian adds CWDM XFP transceivers
AUGUST 19, 2008 -- Optelian (search for (search for Optelian)) has announced 
the availability of new LightGAIN 10-Gbit/sec CWDM XFP transceivers, which the 
company claims create a cost breakthrough in 10-Gbit/sec capacity growth by 
combining the low price points of CWDM with the inventory cost benefits of 
using MSA-compliant pluggable transceivers.
These new CWDM XFP transceivers are a cost-saving solution for 
fiber-constrained customers looking to grow their 10-Gbit/sec services [but] 
who don't need the full migration path provided by DWDM, explains Dave Dal 
Farra, senior Optelian product manager. And in higher growth networks, the low 
first cost and inventory savings can still be taken advantage of by adding up 
to 9 DWDM wavelengths into unused CWDM channels, utilizing Optelian's hybrid 
CWDM/DWDM multiplexers and 10-Gbit/sec tunable DWDM regenerators.

The new CWDM XFP transceivers are fully supported and backwards compatible in 
LightGAIN 6140, 5140, and 3060 systems, plugging into the existing RGN-10GXF 
10-Gbit/sec regenerator card. As part of LightGAIN, the flexibility of CWDM 
pluggable transceivers combines with Optelian's Quick-Turn Custom Passives so 
that custom 10-Gbit/sec CWDM configurations can be delivered as quickly as two 
weeks, claim company representatives.
Also useful for wavelength conversion, reach extension, and regeneration, the 
10-Gbit/sec CWDM XFP transceivers are now available for order. Key 
specifications include coverage from 1471 nm to 1611 nm, plus SONET and Gigabit 
Ethernet compliance for data rates with or without G.709 FEC.

From Alex's older e-mail:

On Fri, 25 Apr 2008, John Lee wrote:
 Subscribe to Lightwave (at no charge) and look at the back issues for 
 networks. Show up at Supercom or OFC or what is replacing them and get the 
 latest on ROADM, full channel tunable lasers and maintenance costs.

 What size of network do you want to grow to before replacing the optical link 
 equipment including ILAs?

 Most any org can cost justify a CWDM / CAN since you can add one fiber pair 
 at a time and one lambda per fiber pair.

 DWDM gear is much more expensive and is aimed at 20 to 40 lambdas per
 fiber for service providers while UDWDM and ULHWAN are aimed at trans
 oceanic links and are very very expensive.
DWDM gear is not expensive. Passive muxes cost little. Active
transceivers cost money but not very expensive at all.
Check out these two presentations (by yours truly et al):
http://www.nanog.org/mtg-0606/pdf/lightning-talks/4-pilosov.pdf
http://www.nanog.org/mtg-0610/presenter-pdfs/pilosov.pdf
-alex



From: Zed Usser [EMAIL PROTECTED]
Sent: Saturday, August 30, 2008 2:54 PM
To: [EMAIL PROTECTED]
Subject: 10GE CWDM

Hi!

I seem to suffer from an acute lack of 10GE CWDM optics options. Is it just me 
or am I just looking in all the wrong places?

You'd think that by now there would be an upgrade market from 1GE to 10GE. DWDM 
wavelenghts are not always available, but CWDM often are.

- Zed

RE: Revealed: The Internet's well known BGP behavior

[John Lee]

1. The technique is not new it is well known BGP behavior and not stealthy to 
people who route for a living.

2. When your networks use VPNs, MPLS, IPsec, SSL et al you can control what 
packets are going where.

3. When you are running some number of trace routes per hour to see how and 
where your packets are going you spot the additional hops.

4. If you do cold potatoe routing and know where you peering points are and 
what the acls and peering policies are it is more difficult to hijack.

And finally you use high speed optical paths or broad band ISDN (ATM) why route 
when you can deterministically switch.

John (ISDN) Lee :)


From: Frank [EMAIL PROTECTED]
Sent: Wednesday, August 27, 2008 8:47 PM
To: NANOG list
Subject: Revealed: The Internet's Biggest Security Hole

http://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html

Two security researchers have demonstrated a new technique to stealthily
intercept internet traffic on a scale previously presumed to be unavailable
to anyone outside of intelligence agencies like the National Security
Agency.

The tactic exploits the internet routing protocol BGP (Border Gateway
Protocol) to let an attacker surreptitiously monitor unencrypted internet
traffic anywhere in the world, and even modify it before it reaches its
destination.

The demonstration is only the latest attack to highlight fundamental
security weaknesses in some of the internet's core protocols. Those
protocols were largely developed in the 1970s with the assumption that every
node on the then-nascent network would be trustworthy.  The world was
reminded of the quaintness of that assumption in July, when researcher Dan
Kaminsky 
disclosedhttp://blog.wired.com/27bstroke6/2008/07/details-of-dns.htmla
serious vulnerability in the DNS system. Experts say the new
demonstration
targets a potentially larger weakness.

It's a huge issue. It's at least as big an issue as the DNS issue, if not
bigger, said Peiter Mudge Zatko, noted computer security expert and
former member of the L0pht hacking group, who testified to Congress in 1998
that he could bring down the internet in 30 minutes using a similar BGP
attack, and disclosed privately to government agents how BGP could also be
exploited to eavesdrop. I went around screaming my head about this about
ten or twelve years ago We described this to intelligence agencies and
to the National Security Council, in detail.

The man-in-the-middle attack exploits BGP to fool routers into re-directing
data to an eavesdropper's network.

Anyone with a BGP router (ISPs, large corporations or anyone with space at a
carrier 
hotelhttp://www.fubra.com/blog/2007/10/mac-mini-bgp-routers-part-2.html)
could intercept data headed to a target IP address or group of addresses.
The attack intercepts only traffic headed *to* target addresses, not from
them, and it can't always vacuum in traffic within a network -- say, from
one ATT customer to another.

The method conceivably could be used for corporate espionage, nation-state
spying or even by intelligence agencies looking to mine internet data
without needing the cooperation of ISPs.

BGP eavesdropping has long been a theoretical weakness, but no one is known
to have publicly demonstrated it until Anton Tony Kapela, data center and
network director at 5Nines Data http://www.5ninesdata.com/, and Alex
Pilosov, CEO of Pilosoft http://www.pilosoft.com/, showed their technique
at the recent DefCon hacker conference. The pair successfully intercepted
traffic bound for the conference network and redirected it to a system they
controlled in New York before routing it back to DefCon in Las Vegas.

The technique, devised by Pilosov, doesn't exploit a bug or flaw in BGP. It
simply exploits the natural way BGP works.

We're not doing anything out of the ordinary, Kapela told Wired.com.
There's no vulnerabilities, no protocol errors, there are no software
problems. The problem arises (from) the level of interconnectivity that's
needed to maintain this mess, to keep it all working.

The issue exists because BGP's architecture is based on trust. To make it
easy, say, for e-mail from Sprint customers in California to reach
Telefonica customers in Spain, networks for these companies and others
communicate through BGP routers to indicate when they're the quickest, most
efficient route for the data to reach its destination. But BGP assumes that
when a router says it's the best path, it's telling the truth. That
gullibility makes it easy for eavesdroppers to fool routers into sending
them traffic.

Here's how it works. When a user types a website name into his browser or
clicks send to launch an e-mail, a Domain Name System server produces an
IP address for the destination. A router belonging to the user's ISP then
consults a BGP table for the best route. That table is built from
announcements, or advertisements, issued by ISPs and other networks --
also known as Autonomous Systems, or ASes -- 

RE: Revealed: The Internet's well known BGP behavior

[John Lee]

Patrick,

VPN's and MPLS control intermediate hops and IPsec and SSL do not allow the 
info to be seen.

Rewriting the TTL only hides the number of hop count, trace route will still 
show the hops the packet has transited.

John (ISDN) Lee


From: Patrick W. Gilmore [EMAIL PROTECTED]
Sent: Wednesday, August 27, 2008 11:18 PM
To: NANOG list
Subject: Re: Revealed: The Internet's well known BGP behavior

On Aug 27, 2008, at 11:07 PM, John Lee wrote:

 1. The technique is not new it is well known BGP behavior and not
 stealthy to people who route for a living.

Using existing technology in novel ways is still novel.  Plus it makes
the technique more accessible.  (Perhaps that is not a good thing?)


 2. When your networks use VPNs, MPLS, IPsec, SSL et al you can
 control what packets are going where.

No, you cannot.  You can only ensure your end points are the end
points you think they are.  In no way, shape, or form do things like
IPsec, SSL, etc. verify or control the intermediate hops.


 3. When you are running some number of trace routes per hour to see
 how and where your packets are going you spot the additional hops.

The presentation specifically shows hiding the hops by re-writing
TTLs.  Perhaps you do not understand this attack as well as you thought?


 4. If you do cold potatoe routing and know where you peering points
 are and what the acls and peering policies are it is more difficult
 to hijack.

Would that network operators were so diligent.


 And finally you use high speed optical paths or broad band ISDN
 (ATM) why route when you can deterministically switch.

Because people want to be able to reach the entire planet with a
single port and without deterministically creating paths to every
single end point.

Why use ISDN (ATM) when you can do something useful?

--
TTFN,
patrick

RE: Revealed: The Internet's well known BGP behavior

[John Lee]

Adrian,

The traceroute utility that I used gave me a list of hops that the packet I was 
interested in transited and a time when it transited the hop. When the TTL was 
reached it would terminate the listing.

When ever I had performance issues on my networks or with my networks links it 
would indicate if the standard route was being taken or another one. When 
certain links went down several additional hops would be added to the list.

John (ISDN) Lee


From: Adrian Chadd [EMAIL PROTECTED]
Sent: Wednesday, August 27, 2008 11:32 PM
To: John Lee
Cc: Patrick W. Gilmore; NANOG list
Subject: Re: Revealed: The Internet's well known BGP behavior

On Wed, Aug 27, 2008, John Lee wrote:
 Patrick,

 VPN's and MPLS control intermediate hops and IPsec and SSL do not allow the 
 info to be seen.

 Rewriting the TTL only hides the number of hop count, trace route will still 
 show the hops the packet has transited.

No, traceroute shows the hops which returned time to live exceeded.

This only maps to the hops the packet has transited if the TTL is setup
and decremented correctly.




Adrian

RE: speaking of slightly OT but perhaps still operational content

[John Lee]

Unless they have installed a DAS system for cell signal transport or a number 
of micro or nano cells in the building they will have congestion. But what is a 
political convention without a little congestion.

John (ISDN) Lee


From: Dorn Hetzel [EMAIL PROTECTED]
Sent: Tuesday, August 26, 2008 12:50 PM
To: NANOG list
Subject: speaking of slightly OT but perhaps still operational content

I noticed where the democrats plan to ask a stadium full of people to all
use their cellphones at the same time (on Thursday, I believe)

Any thoughts on how useable cell service will or wont be in the vicinity of
this event? :)

-Dorn

RE: IP Fragmentation

[John Lee]

Glen,

With the v4 networks that I have worked on in the past, they did not do end to 
end MTU discovery before sending packets. The TTL had to be set appropriately 
so that if you had low speed links, for example, the packet and response would 
get through in time. On our DS3 (T3) and OC-3c packet links we did 4k, 9k, and 
16k packet sizes for video and file transfers.

At the other end of the spectrum are civilian and military systems with 
tactical links, both wired and radio, with low bit rates and header compression 
on IP and TCP packets. Speeds range from 300 -9,600 bps, 16k, 32k, 64k and 
Nx64k bps links that can do packet fragmentation and adding proprietary ECC 
codes for the radio links. Some systems strip the IP packet and use standard or 
non-standard link layer protocols across the mediums. Some of these systems are 
store and forward so that the computer/router that is connected to the low 
speed link will ack the packet for the high speed network connection and buffer 
it up until it can be sent on the lower speed system.

IMHO current IPv6 protocols ignore the lower end segment by specifying the 
lowest MTU for the circuit be the MTU for the entire circuit and not allow 
fragmentation. I do not see this as an efficient use of high speed network 
resources and local link management can handle fragmentation just fine.

John (ISDN) Lee

A slightly different History Channel.

From: Glen Kent [EMAIL PROTECTED]
Sent: Wednesday, August 20, 2008 12:13 PM
To: OPS Gurus
Subject: IP Fragmentation

Hi,

Do transit routers in the wild actually get to do IP fragmentation
these days? I was wondering if routers actually do it or not, because
the source usually discovers the path MTU and sends its data with the
least supported MTU. Is this true?

Even if this is, then this would break for multicast IP. The source
cannot determine which receivers would get interested in the traffic
and what capacities the links connecting them would support. So, a
source would send IP packets with some size, and theres a chance that
one of the routers *may* have to fragment those IP packets before
passing it on to the next router.

I would wager that the vendors and operators would want to avoid IP
fragmentation since thats usually done in SW (unless you've got a very
powerful ASIC or your box is NP based).

Thanks,
Glen

RE: IP Fragmentation (correction)

[John Lee]

Correction.

TTL needs to be set to sufficiently large number of hops to allow the packet to 
get through the number of hops and the timers need to be set to allow the 
packet to transit the network and the low speed links before timing out and 
retransmitting the packet.

John (ISDN) Lee


From: John Lee [EMAIL PROTECTED]
Sent: Wednesday, August 20, 2008 2:10 PM
To: Glen Kent; OPS Gurus
Subject: RE: IP Fragmentation

Glen,

With the v4 networks that I have worked on in the past, they did not do end to 
end MTU discovery before sending packets. The TTL had to be set appropriately 
so that if you had low speed links, for example, the packet and response would 
get through in time. On our DS3 (T3) and OC-3c packet links we did 4k, 9k, and 
16k packet sizes for video and file transfers.

At the other end of the spectrum are civilian and military systems with 
tactical links, both wired and radio, with low bit rates and header compression 
on IP and TCP packets. Speeds range from 300 -9,600 bps, 16k, 32k, 64k and 
Nx64k bps links that can do packet fragmentation and adding proprietary ECC 
codes for the radio links. Some systems strip the IP packet and use standard or 
non-standard link layer protocols across the mediums. Some of these systems are 
store and forward so that the computer/router that is connected to the low 
speed link will ack the packet for the high speed network connection and buffer 
it up until it can be sent on the lower speed system.

IMHO current IPv6 protocols ignore the lower end segment by specifying the 
lowest MTU for the circuit be the MTU for the entire circuit and not allow 
fragmentation. I do not see this as an efficient use of high speed network 
resources and local link management can handle fragmentation just fine.

John (ISDN) Lee

A slightly different History Channel.

From: Glen Kent [EMAIL PROTECTED]
Sent: Wednesday, August 20, 2008 12:13 PM
To: OPS Gurus
Subject: IP Fragmentation

Hi,

Do transit routers in the wild actually get to do IP fragmentation
these days? I was wondering if routers actually do it or not, because
the source usually discovers the path MTU and sends its data with the
least supported MTU. Is this true?

Even if this is, then this would break for multicast IP. The source
cannot determine which receivers would get interested in the traffic
and what capacities the links connecting them would support. So, a
source would send IP packets with some size, and theres a chance that
one of the routers *may* have to fragment those IP packets before
passing it on to the next router.

I would wager that the vendors and operators would want to avoid IP
fragmentation since thats usually done in SW (unless you've got a very
powerful ASIC or your box is NP based).

Thanks,
Glen

RE: SLAAC(autoconfig) vs DHCPv6 vs IP Address Lifecycle Management

[John Lee]

Scott,

There are solutions that support both static, quasi-static, also driving DHCPv6 
servers and Dynamic DNS updates. There are networks that have deployed IPal to 
automate and consolidate their IPv4 and IPv6 block allocations and interface 
assignments. Router Prefix delegation, SLAAC and DHCPv6 were implemented to 
have a more automated method of IPv6 address assignments because of the large 
potential number of IPv6 addresses to be assigned in a next generation network.

IPal does address block assignments for Prefix delegation, SLAAC and DHCPv6 
support. It does IPv6 interface assignments of /64 EUI-64, /64 random, /126, 
/127 and /128 and generate the Dynamic DNS updates for those assignments.

E-mail me off list if you want any additional information.

John (ISDN) Lee

From: Howard C. Berkowitz [EMAIL PROTECTED]
Sent: Monday, August 18, 2008 3:42 PM
To: nanog@nanog.org
Subject: RE: SLAAC(autoconfig) vs DHCPv6

To try to stay operational about this, I have a reality testing question
I've used in IPv4 and, for that matter, bridged networks:

If you want to test a resource, be it the end user or an infrastructure
interface, how do you know how to foo it (foo being some value of ping,
traceroute, look it up in SNMP/NetFlow, etc)?

I submit that if you use dynamic assignment of any sort, you really have to
have DNS dynamic update, so you can use a known name to query the function
that's indexed by address.  Otherwise, static addresses become rather
necessary if you want to check a resource.

This was especially a question when L2 was in and routing was out: how do
you ping a MAC address?

Howard

-Original Message-
From: Scott Weeks [mailto:[EMAIL PROTECTED]
Sent: Monday, August 18, 2008 3:34 PM
To: nanog@nanog.org
Subject: SLAAC(autoconfig) vs DHCPv6



-- [EMAIL PROTECTED] wrote: 
From: TJ [EMAIL PROTECTED]

As a general rule, most clients are following the If we gave them static
IPv4 addresses we will give them static IPv6 addresses (infrastructure,
servers, etc).  The whole SLAAC(autoconfig) vs DHCPv6 is a separate (albeit
related) conversation ...



I'm still an IPv6 wussie and would like to learn more before moving forward,
so would anyone care to share info on experiences with this decision?

scott

Re: [NANOG] DWDM More Details

[John Lee]

Scott,

Do you want

  CWDM - Course Wave Division Multiplexing - 100 nm optical 
spacing   1 - 10 x 2.5 - 10 Gbps lambdas
  DWDM - Dense Wave Division Multiplexing   -   =50 nm optical 
spacing  20 - 40  x 2.5 - 10 Gbps
UDWDM - Ultra Dense Wave Division Multiplexing -50 nm optical 
spacing  40 - 80  x 2.5 - 10 Gbps

What size area do you want

CAN - Campus Area Network   1 - 5 MilesShort Optics, No amplifiers
   MAN - Metro Area Network 10 - 40 Miles  Medium Optics, No amplifiers
   WAN - Wide Area Network   150   Miles between In Line Amplifiers (ILA)  
Long haul optics, EDFA or Ramiun Amps
ULHWAN - Ultra Long Haul600 - 800 Miles between ILA, ULH optics, Ramiun 
Amps

What type of fiber do you want to use?

SMF, Zero dispersion, phase shifted, etc.. This one you usually cannot control 
fiber since it depends on who you lease or buy the fiber from.

Running the fiber cost the money.

There are now a large number of regional fiber providers with Level (3) having 
the most available dark or lite fiber nationally in the US.

Alcaltel/Lucent, ADVA, Ciena, Cisco and the Chinese are normal list of optical 
equipment providers and Siemens, Ericson and others.

Subscribe to Lightwave (at no charge) and look at the back issues for networks. 
Show up at Supercom or OFC or what is replacing them and get the latest on 
ROADM, full channel tunable lasers and maintenance costs.

What size of network do you want to grow to before replacing the optical link 
equipment including ILAs?

Most any org can cost justify a CWDM / CAN since you can add one fiber pair at 
a time and one lambda per fiber pair.

DWDM gear is much more expensive and is aimed at 20 to 40 lambdas per fiber for 
service providers while UDWDM and ULHWAN are aimed at trans oceanic links and 
are very very expensive.

John (ISDN) Lee


From: Scott E. MacKenzie [EMAIL PROTECTED]
Sent: Friday, April 25, 2008 4:00 AM
To: NANOG
Subject: [NANOG] DWDM

Does anyone know where I can locate a list of DWDM networks deployed for
Education, Science  Research, and Commercialization?

We need to determine the practicality of DWDM use...


Scott

___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog

___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog

Re: [NANOG] DWDM More Details

[John Lee]

alex,

In your talk, I agree that the CAN with your CWDM is not that expensive but you 
also mention that the tighter DWDM with long haul optics is expensive ie 
Everybody knows how to do (active) xWDM by giving a lot of money to (insert 
vendor of choice]:

When you talk about the tighter itu spacing for real DWDM and the lasers with 
fiber that can handle the power, jitter, chromatic dispersion et al. the optics 
you mention will not handle that.

We have all duct taped optical systems on campus for the lab and across the 
state of Georgia see the Peach Net map.

What is the largest number of lambdas you have actually run on a single fiber 
with your duct tape system and how bad was the optical cross talk?

john


From: Alex Pilosov [EMAIL PROTECTED]
Sent: Friday, April 25, 2008 1:37 PM
To: John Lee
Cc: Scott E. MacKenzie; NANOG
Subject: Re: [NANOG] DWDM More Details

On Fri, 25 Apr 2008, John Lee wrote:

 Subscribe to Lightwave (at no charge) and look at the back issues for 
 networks. Show up at Supercom or OFC or what is replacing them and get the 
 latest on ROADM, full channel tunable lasers and maintenance costs.

 What size of network do you want to grow to before replacing the optical link 
 equipment including ILAs?

 Most any org can cost justify a CWDM / CAN since you can add one fiber pair 
 at a time and one lambda per fiber pair.

 DWDM gear is much more expensive and is aimed at 20 to 40 lambdas per
 fiber for service providers while UDWDM and ULHWAN are aimed at trans
 oceanic links and are very very expensive.

DWDM gear is not expensive. Passive muxes cost little. Active
transceivers cost money but not very expensive at all.

Check out these two presentations (by yours truly et al):
http://www.nanog.org/mtg-0606/pdf/lightning-talks/4-pilosov.pdf
http://www.nanog.org/mtg-0610/presenter-pdfs/pilosov.pdf

-alex

___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog