Re: The End-To-End Internet (was Re: Blocking MX query)

[Eliot Lear]

On 9/6/12 8:27 PM, Owen DeLong wrote:
> Despite my scepticism of the overall project, I find the above claim a
> little hard to accept.  RFC 2052, which defined SRV in an
> experiment, came out in 1996.  SRV was moved to the standards track in
> 2000.  I've never heard an argument why it won't work, and we know
> that SRV records are sometimes in use.  Why couldn't that mechanism be
> used more widely? 
>
> If browsers started implementing it, it could.

This is currently being discussed in the httpbis working group as part
of the http 2.0 discussion.  Also, I'll note that at least one browser
has implemented XMPP without the mandatory SRV record, and it's next to
useless for XMPP (in fact it seems to only work with a handful of broken
XMPP implementations), so look for SRV in at least one browser in the
next year or so, I'd guess.


>
> I suppose the more accurate/detailed statement would be:
>
> Without modifying every client on the internet, there is no way for the
> clients trying to reach you to reliably be informed of this port number
> situation.
>
> If you're going to touch every client, it's easier to just do IPv6.
>

Well, this depends on who you think "you" is.  The browser gang
regularly touches many MANY (but not all) clients.

Eliot

Re: The End-To-End Internet (was Re: Blocking MX query)

[Jimmy Hess]

On 9/6/12, Masataka Ohta  wrote:
> Owen DeLong wrote:
>> You're demanding an awful lot of changes to the entire internet to
> All that necessary is local changes on end systems of those who
> want the end to end transparency.

Achieving "end to end", and breaking interoperability while
introducing a level of complexity and points of failure that noone
will accept, is no good.  I refer you back to RFC1925  number (6).

If you had to modify the implementation on endpoints that want to
communicate end-to-end,  then by definition you don't have
transparency. The inability to communicate end-to-end with unmodified
endpoints  makes it non-transparent, and is itself a break of the
principle.

UPnP is not robust enough either for the suggested application.


The RFC3102  you mention  doesn't have acceptance;  the concept of
RSIP was not proven tenable, that it actually works or scales and can
be implemented reliably with real applications on real networks in the
first place.

Achieving true 'end to end' with such a scheme would require
alterations to many protocol standards which didn't happen,  and there
would be many interoperability breaks.



>
> There is no changes on the Internet.
>   Masataka Ohta
--
-JH

Re: Traffic Burstiness Survey

[Heath Jones]

Hi Monia,

'Burst' is a very broad term. It would be useful to clarify to what you are
referring.. I can think of a few possibilities:

- Data Transmission: The length of an uninterrupted flow of information.
- Traffic Engineering: The ability for traffic to temporarily exceed it's
allocated (average) bandwidth share.
- Internal Event: A backup (scheduled) or a server failure (adhoc) altering
traffic patterns.
- External Event: Marketing campaign / event coinciding with increased
traffic towards say, a website.

Perhaps -> Over what period of time is a 'Burst'..?


Cheers,
Heath


On Sun, Sep 9, 2012 at 10:23 AM, Monia Ghobadi  wrote:

> Dear Nanog members,
>
> I am a PhD student at University of Toronto and I am working on traffic
> burstiness in data centers. In the following I am asking two questions to
> raise motivation for my research. I appreciate if anyone could answer these
> questions to their best knowledge. *The questions are:*
>
> 1) ‘Bursty’ is a word with no agreed meaning. How do you define a bursty
> traffic?
> 2) If you are involved with a data center, is your data center traffic
> bursty?
>-- If yes,
>  -- Do you think that it will be useful to supress the burstiness
> in your traffic? (For example by pacing the traffic into shorter bursts)
> -- If no:
> -- Are you already supressing the burstiness? How?
>  -- Would you anticipate the traffic becoming burstier in the
> future?
>
> Thanks,
> Monia
>
> --
> Monia Ghobadi
> PhD Student
> University of Toronto
> http://www.cs.utoronto.ca/~monia/
>

Re: Are people still building SONET networks from scratch?

[Mark Andrews]

In message 
, david peahi writes:
> In my neck of the woods, critical locations often exist "in the middle of
> nowhere", resulting in underserved facilities, where best effort networks
> such as metro Ethernet cannot be trusted to remain available 24x7x365. Many
> times, during prime business hours,  I will see a telco metro Ethernet
> spanning tree convergence which results in my traffic re-routing for 20-30
> seconds over my private backup network path, then switching back to the
> metro Ethernet path after the telco technicians have finished their
> maintenance. Several times when I have called in a trouble ticket, the
> telco tech has asked "what is the big deal, it was only a 20 second
> outage?". In the Enterprise environment, a planned spanning tree
> convergence in the middle of business hours is one of the quickest ways for
> a network engineer to be relieved of their duties, but apparently the bar
> is considerably lower in the telco environment.
> Not only that, but the telco SLAs associated with metro Ethernet are
> totally bogus, with a best round trip SLA of 20 milliseconds, ranging up to
> 50 milliseconds for "bronze" service. For short distances of 100 miles or
> less (rule of thumb is that light travels over fiber at 0.80 x speed of
> light, or 1000 miles in 10 milliseconds), an SLA of 20-50 milliseconds
>  amounts to fraud,  just another way for the telcos to scam the consumer.
> The tone of many of the entries on this thread where the user is depicted
> as being unreasonable, underscores the need for a coordinated national
> broadband policy in the USA, based upon the Australian model in which the
> government is building out fiber to every residence and business, no matter
> where they are located.

The NBN is to be delivered over a mixture of fibre (93% of homes), wireless
and satellite services[1].

[1] http://www.nbn.gov.au/about-the-nbn/what-is-the-nbn/

> Regards,
> 
> David
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Heads-Up: GoDaddy Broke the Interwebs...

[Operations Dallas]

I thought I saw an article on routergod.com from Dance Patrick regarding 
anycast DNS..
~oliver

Sent via DynaTAC. Please forgive spelling and grammar.

-Original Message-
From: bill.ing...@t-systems.com
Date: Mon, 10 Sep 2012 19:13:27 
To: ; 
Subject: RE: Heads-Up: GoDaddy Broke the Interwebs...


Looks like this may be a DDoS attack from Anonymous:

http://techcrunch.com/2012/09/10/godaddy-outage-takes-down-millions-of-sites/


-Original Message-
From: Aaron C. de Bruyn [mailto:aa...@heyaaron.com] 
Sent: Monday, September 10, 2012 1:07 PM
To: NANOG mailing list
Subject: Heads-Up: GoDaddy Broke the Interwebs...

For the last ~15 minutes I've been receiving complaints about DNS issues.  
GoDaddy DNS is apparently b0rked.  I'm also seeing a lot of tweets about their 
hosting and VPS being down.  I'm unable to access the control panel for one of 
my customer accounts.


-A

Traffic Burstiness Survey

[Monia Ghobadi]

Dear Nanog members,

I am a PhD student at University of Toronto and I am working on traffic
burstiness in data centers. In the following I am asking two questions to
raise motivation for my research. I appreciate if anyone could answer these
questions to their best knowledge. *The questions are:*

1) ‘Bursty’ is a word with no agreed meaning. How do you define a bursty
traffic?
2) If you are involved with a data center, is your data center traffic
bursty?
   -- If yes,
 -- Do you think that it will be useful to supress the burstiness
in your traffic? (For example by pacing the traffic into shorter bursts)
-- If no:
-- Are you already supressing the burstiness? How?
 -- Would you anticipate the traffic becoming burstier in the
future?

Thanks,
Monia

--
Monia Ghobadi
PhD Student
University of Toronto
http://www.cs.utoronto.ca/~monia/

Re: Are people still building SONET networks from scratch?

[Matthew Petach]

On Mon, Sep 10, 2012 at 2:11 PM, Nick Hilliard  wrote:
> On 10/09/2012 21:43, Matthew Petach wrote:
>> If service is critical enough to me that 20 second hiccups make
>> a difference, I'll find two providers to provide connectivity
>
> um, what do you mean, "two providers"?
>
>> to the location via relatively cheap waves
>
> This *is* a troll, right...?
>
> just sayin' that not everywhere has functional competition...
>
> Nick

*heh*  Fair enough.  I guess it's really a question of
what scale you're looking at.  Even when building a
greenfield datacenter in the middle of an empty field
in an out-of-the-way corner of a state with cheap
electricity, you can generally find two fiber providers
that will run fiber into the location based on the
premise of the long-term payback a 50MW datacenter
brings with it.

At smaller scales, I could see how it could become
more challenging to convince a second provider it's
worth their while to build out to your location.

point  taken--thanks!

Matt

Re: The End-To-End Internet (was Re: Blocking MX query)

[Masataka Ohta]

William Herrin wrote:

> In case Nick's comment wasn't obvious enough:

Anything written in RFC1796 should be ignored, because RFC1796, an
informational, not standard track, RFC, states so.

It's so obvious.

> RFC 1796:

> It is a regrettably well spread misconception that publication as an
> RFC provides some level of recognition.  It does not, or at least not
> any more than the publication in a regular journal."

Your silliness, too, is appreciated.

> End-to-end is generally described as a
> layer 3 phenomenon.

Read the original paper on it:

http://groups.csail.mit.edu/ana/Publications/PubPDFs/End-to-End%20Arguments%20in%20System%20Design.pdf

to find that the major example of the paper is file transfer,
an application.

> we are for practical, operational
> purposes just shy of -never- talking about or using that kind of NAT.

For practical operational purposes, it is enough that PORT command
of ftp works transparently.

Masataka Ohta

Level3 BGP Issue

[Dennis Burgess]

I have a prefix that is having an issue with BGP, its all inside of
L3If there is someone that would be willing to assist with L3,
shoot me a e-mail offlist J 

 

Dennis Burgess, 

 

Re: The End-To-End Internet (was Re: Blocking MX query)

[William Herrin]

On Sun, Sep 9, 2012 at 6:24 PM, Masataka Ohta
 wrote:
> Oliver wrote:
 You're basically redefining the term "end-to-end transparency" to suit
 your own
>>> Already in RFC3102, which restrict port number ranges, it is
>>> stated that:
>>>
>>> This document examines the general framework of Realm Specific IP
>>> (RSIP).  RSIP is intended as a alternative to NAT in which the end-
>>> to-end integrity of packets is maintained.  We focus on
>>> implementation issues, deployment scenarios, and interaction with
>>> other layer-three protocols.
>>
>> Just because something is documented in RFC does not automatically make it a
>> standard, nor does it necessarily make anyone care.
>
> That's not a valid argument against text in the RFC proof read by
> the RFC editor as the evidence of established terminology of the
> Internet community.

In case Nick's comment wasn't obvious enough:

RFC 1796:

"Not All RFCs Are Standards

It is a regrettably well spread misconception that publication as an
RFC provides some level of recognition.  It does not, or at least not
any more than the publication in a regular journal."

RFC 3102:

"This memo defines an Experimental Protocol for the Internet
community.  It does not specify an Internet standard of any kind."


As to your original point that software could be constructed that
restores end-to-end through a NAT device by some kind of dynamic but
published assignment of incoming ports to specific hosts behind the
NAT... that's not really true. End-to-end is generally described as a
layer 3 phenomenon. Dinking around with ports means you're at layer 4.
Which means that only specific pre-programmed transports can pass even
it you would like all protocols to be able to.

There is another technology, also called NAT and described in RFC
1631, which translates layer 3 addresses 1:1, exactly one address
inside for one address outside. While it's possible to talk about
end-to-end with that technology, we are for practical, operational
purposes just shy of -never- talking about or using that kind of NAT.

Regards,
Bill Herrin


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

Re: Are people still building SONET networks from scratch?

[Nick Hilliard]

On 10/09/2012 21:43, Matthew Petach wrote:
> If service is critical enough to me that 20 second hiccups make
> a difference, I'll find two providers to provide connectivity 

um, what do you mean, "two providers"?

> to the location via relatively cheap waves

This *is* a troll, right...?

just sayin' that not everywhere has functional competition...

Nick

[NANOG-announce] Upcoming NANOG mail list maintenance notification - 13-Sept-2012

[Randy Epstein]

On Thursday, September 13, 2012 beginning at 6 AM Eastern, the NANOG mail
list service will be unavailable. Mailman will be upgraded and moved to a
new location, and all lists will be synced, thus ensuring that no messages
or archives are lost in the transition.  We expect the outage to last no
longer than 30 minutes.

Regards,

Randy Epstein
NANOG CC Chair

On behalf of the NANOG Communications Committee



___
NANOG-announce mailing list
nanog-annou...@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

Re: Are people still building SONET networks from scratch?

[Jared Mauch]

Matthew,

On Sep 10, 2012, at 4:43 PM, Matthew Petach  wrote:

> This *was* a troll, right…?

I suspect it wasn't.  There's some people who equate various types of services 
with others.

I've been following this thread with some head-scratching going on.  Some folks 
think "ethernet" can only be a metro solution with STP/RSTP/MSTP/VPLS in the 
"cloud" of another network.

Others realize that saying ethernet as the encoding on the PHY is entirely 
different. (lan-phy, wan-phy, otu2, otu2e, etc).

When it comes to talking "SONET" vs "Ethernet" it is good to be very explicit.  
There are a variety of ways to provide a redundant and protected service with 
ethernet vs sonet/sdh framing.

Some of the carrier provided "ethernet" products result in weird pricing, or 
plain fear.  I recall one ILEC that got an entire team on the phone with me for 
an ask about a 100m service purchase, because it was "huge" to them.  Their 
price reflected it as well :)  It was easier to stick with the city fiber 
network for backhaul as the pricing was sane.

- Jared

Re: The End-To-End Internet (was Re: Blocking MX query)

[Masataka Ohta]

Nick Hilliard wrote:

>>> Just because something is documented in RFC does not automatically make it a
>>> standard, nor does it necessarily make anyone care.
>>
>> That's not a valid argument against text in the RFC proof read by
>> the RFC editor as the evidence of established terminology of the
>> Internet community.
> 
> you may want to read rfc 1796, and then retract what you said because it
> sounds silly.

Anything written in RFC1796 should be ignored, because RFC1796, an
informational, not standard track, RFC, states so.

Or, is it time to retract your silliness?

Masataka Ohta

Re: Are people still building SONET networks from scratch?

[Matthew Petach]

This *was* a troll, right...?

On Mon, Sep 10, 2012 at 10:55 AM, david peahi  wrote:
> In my neck of the woods, critical locations often exist "in the middle of
> nowhere", resulting in underserved facilities, where best effort networks
> such as metro Ethernet cannot be trusted to remain available 24x7x365. Many
> times, during prime business hours,  I will see a telco metro Ethernet
> spanning tree convergence which results in my traffic re-routing for 20-30
> seconds over my private backup network path, then switching back to the
> metro Ethernet path after the telco technicians have finished their
> maintenance. Several times when I have called in a trouble ticket, the
> telco tech has asked "what is the big deal, it was only a 20 second
> outage?". In the Enterprise environment, a planned spanning tree
> convergence in the middle of business hours is one of the quickest ways for
> a network engineer to be relieved of their duties, but apparently the bar
> is considerably lower in the telco environment.
> Not only that, but the telco SLAs associated with metro Ethernet are
> totally bogus, with a best round trip SLA of 20 milliseconds, ranging up to
> 50 milliseconds for "bronze" service. For short distances of 100 miles or
> less (rule of thumb is that light travels over fiber at 0.80 x speed of
> light, or 1000 miles in 10 milliseconds), an SLA of 20-50 milliseconds
>  amounts to fraud,  just another way for the telcos to scam the consumer.
> The tone of many of the entries on this thread where the user is depicted
> as being unreasonable, underscores the need for a coordinated national
> broadband policy in the USA, based upon the Australian model in which the
> government is building out fiber to every residence and business, no matter
> where they are located.
>
> Regards,
>
> David

If service is critical enough to me that 20 second hiccups make
a difference, I'll find two providers to provide connectivity to the
location via relatively cheap waves, and I'll run link-node protection
at my layer to get fast reconvergence in the sub-second range.
And I'd warrant it'll still come out cheaper than the government-built
costs we see in Australia.

I really, really don't think more government intervention is the right
answer.

Matt

Re: Heads-Up: GoDaddy Broke the Interwebs...

[Anurag Bhatia]

Yeah, I heard about downtime from couple of our clients.



Seems like US West coast datacenter has issues specially with DNS. I see
DNS working fine in Asia (via Singapore nodes), and in other parts of US as
well.


Here's a failing DNS node (checking from my Europe test server)



traceroute to 216.69.185.46 (216.69.185.46), 30 hops max, 60 byte packets
 1  gw.giga-dns.com (91.194.90.1)  1.141 ms  1.134 ms  1.346 ms
 2  62.140.24.125 (62.140.24.125)  1.835 ms  1.830 ms  1.820 ms
 3  ae-19-19.ebr1.Frankfurt1.Level3.net (4.69.153.246)  6.560 ms  6.560 ms
 6.552 ms
 4  ae-46-46.ebr2.Paris1.Level3.net (4.69.143.138)  15.286 ms
ae-47-47.ebr2.Paris1.Level3.net (4.69.143.142)  15.270 ms
ae-45-45.ebr2.Paris1.Level3.net (4.69.143.134)  15.246 ms
 5  ae-42-42.ebr2.Washington1.Level3.net (4.69.137.54)  95.934 ms  95.928
ms ae-43-43.ebr2.Washington1.Level3.net (4.69.137.58)  95.820 ms
 6  ae-82-82.csw3.Washington1.Level3.net (4.69.134.154)  94.157 ms
ae-92-92.csw4.Washington1.Level3.net (4.69.134.158)  96.707 ms  98.696 ms
 7  ae-23-70.car3.Washington1.Level3.net (4.69.149.69)  95.490 ms
ae-43-90.car3.Washington1.Level3.net (4.69.149.197)  93.731 ms  96.204 ms
 8  THE-GO-DADD.car3.Washington1.Level3.net (4.79.168.54)  94.708 ms
 97.039 ms  95.756 ms
 9  208.109.112.253 (208.109.112.253)  95.244 ms  94.401 ms  94.388 ms
10  208.109.112.253 (208.109.112.253)  94.378 ms  93.864 ms  95.172 ms
11  208.109.113.58 (208.109.113.58)  94.387 ms  94.359 ms  94.042 ms
12  * * *





I am very curious to know what prevents Godaddy from withdrawling prefixes
from that specific region and let other working datacenters to handle DNS?
Can that cause issue on other stable nodes during DOS attack?




On Tue, Sep 11, 2012 at 12:43 AM,  wrote:

> Looks like this may be a DDoS attack from Anonymous:
>
>
> http://techcrunch.com/2012/09/10/godaddy-outage-takes-down-millions-of-sites/
>
>
> -Original Message-
> From: Aaron C. de Bruyn [mailto:aa...@heyaaron.com]
> Sent: Monday, September 10, 2012 1:07 PM
> To: NANOG mailing list
> Subject: Heads-Up: GoDaddy Broke the Interwebs...
>
> For the last ~15 minutes I've been receiving complaints about DNS issues.
>  GoDaddy DNS is apparently b0rked.  I'm also seeing a lot of tweets about
> their hosting and VPS being down.  I'm unable to access the control panel
> for one of my customer accounts.
>
>
> -A
>
>


-- 

Anurag Bhatia
anuragbhatia.com

Linkedin  |
Twitter|
Google+ 

Re: Heads-Up: GoDaddy Broke the Interwebs...

[Steve Meuse]

Of course, it could be a case of Hanlon's Razor.

-Steve

On Mon, Sep 10, 2012 at 3:13 PM,  wrote:

> Looks like this may be a DDoS attack from Anonymous:
>
>
> http://techcrunch.com/2012/09/10/godaddy-outage-takes-down-millions-of-sites/
>
>
> -Original Message-
> From: Aaron C. de Bruyn [mailto:aa...@heyaaron.com]
> Sent: Monday, September 10, 2012 1:07 PM
> To: NANOG mailing list
> Subject: Heads-Up: GoDaddy Broke the Interwebs...
>
> For the last ~15 minutes I've been receiving complaints about DNS issues.
>  GoDaddy DNS is apparently b0rked.  I'm also seeing a lot of tweets about
> their hosting and VPS being down.  I'm unable to access the control panel
> for one of my customer accounts.
>
>
> -A
>
>

RE: Heads-Up: GoDaddy Broke the Interwebs...

[Bill.Ingrum]

Looks like this may be a DDoS attack from Anonymous:

http://techcrunch.com/2012/09/10/godaddy-outage-takes-down-millions-of-sites/


-Original Message-
From: Aaron C. de Bruyn [mailto:aa...@heyaaron.com] 
Sent: Monday, September 10, 2012 1:07 PM
To: NANOG mailing list
Subject: Heads-Up: GoDaddy Broke the Interwebs...

For the last ~15 minutes I've been receiving complaints about DNS issues.  
GoDaddy DNS is apparently b0rked.  I'm also seeing a lot of tweets about their 
hosting and VPS being down.  I'm unable to access the control panel for one of 
my customer accounts.


-A

Re: Heads-Up: GoDaddy Broke the Interwebs...

[chris]

On Mon, Sep 10, 2012 at 2:07 PM, Aaron C. de Bruyn wrote:

> For the last ~15 minutes I've been receiving complaints about DNS
> issues.  GoDaddy DNS is apparently b0rked.  I'm also seeing a lot of
> tweets about their hosting and VPS being down.  I'm unable to access
> the control panel for one of my customer accounts.
>
>
> -A
>
>
This is already being covered on outages list seems be very widespread

Re: Heads-Up: GoDaddy Broke the Interwebs...

[Derek Ivey]

Wow. Their own site is even down.

On Sep 10, 2012, at 2:07 PM, "Aaron C. de Bruyn"  wrote:

> For the last ~15 minutes I've been receiving complaints about DNS
> issues.  GoDaddy DNS is apparently b0rked.  I'm also seeing a lot of
> tweets about their hosting and VPS being down.  I'm unable to access
> the control panel for one of my customer accounts.
> 
> 
> -A
> 

Heads-Up: GoDaddy Broke the Interwebs...

[Aaron C. de Bruyn]

For the last ~15 minutes I've been receiving complaints about DNS
issues.  GoDaddy DNS is apparently b0rked.  I'm also seeing a lot of
tweets about their hosting and VPS being down.  I'm unable to access
the control panel for one of my customer accounts.


-A

Re: Are people still building SONET networks from scratch?

[david peahi]

In my neck of the woods, critical locations often exist "in the middle of
nowhere", resulting in underserved facilities, where best effort networks
such as metro Ethernet cannot be trusted to remain available 24x7x365. Many
times, during prime business hours,  I will see a telco metro Ethernet
spanning tree convergence which results in my traffic re-routing for 20-30
seconds over my private backup network path, then switching back to the
metro Ethernet path after the telco technicians have finished their
maintenance. Several times when I have called in a trouble ticket, the
telco tech has asked "what is the big deal, it was only a 20 second
outage?". In the Enterprise environment, a planned spanning tree
convergence in the middle of business hours is one of the quickest ways for
a network engineer to be relieved of their duties, but apparently the bar
is considerably lower in the telco environment.
Not only that, but the telco SLAs associated with metro Ethernet are
totally bogus, with a best round trip SLA of 20 milliseconds, ranging up to
50 milliseconds for "bronze" service. For short distances of 100 miles or
less (rule of thumb is that light travels over fiber at 0.80 x speed of
light, or 1000 miles in 10 milliseconds), an SLA of 20-50 milliseconds
 amounts to fraud,  just another way for the telcos to scam the consumer.
The tone of many of the entries on this thread where the user is depicted
as being unreasonable, underscores the need for a coordinated national
broadband policy in the USA, based upon the Australian model in which the
government is building out fiber to every residence and business, no matter
where they are located.

Regards,

David
On Thu, Sep 6, 2012 at 9:38 AM, Will Orton  wrote:

> We've run into an issue with a customer that has been confounding us for a
> few
> months as we try to design what they need.
>
> The customer has a location in the relative middle of nowhere that they are
> trying to build a protected OC3 to. Ultimately, their traffic on it will be
> packet data (IP/ethernet, not channelized/voice). But they seem to be
> absolutely 100% set on the idea that they build with Cisco ONS boxes and
> that
> they run and control the D1-D12 bytes in order to manage protection
> switching
> on the OC3 (and have their DCC channel for management).
>
> Since this is the middle of nowhere, we are having to piece it together
> from a
> few runs of dark fiber here and there and lit services from about 3 other
> providers to get from the desired point A to the desired point B. The
> issues
> we seem to be hitting are:
>
> -We seem to be unable to find anyone who sells lit OC3 with D1-D12
> transparency for the client. Sometimes we can get D1-D3, but that's it.
>
> -lit OC3/12/48 is ridiculously expensive comapred to 1g ethernet waves or
> 10g
> waves (choice LAN/WAN ethernet or OC192)
>
> 10g waves are cheap enough that we have entertained the idea of buying
> them and
> putting OC-192/muxponders on the ends to provide the OC-3, but even then
> I'm
> having trouble finding boxes that will do D1-D12 transparency for client
> OC-3.
> Building the whole thing on dark fiber so that we could specify the exact
> equipment on every hop isn't going to happen, as the "protect" path is
> about
> 1000 miles and the geography is such that we don't really have a market
> for all
> the other wasted capacity there would be on that path.
>
> Having much more experience with ethernet/packet/MPLS setups, we are
> trying to
> get the client to admit that 1g/10g waves running ethernet with QoS would
> be as
> good as or better in terms of latency, jitter, and loss for their packet
> data.
> So far they will barely listen to the arguments. And then going the next
> leap
> and showing them that we could work towards <50ms protection switching with
> MPLS/BFD/etc packet-based protocols is another stretch.
>
>
> Am I missing something here that my customer isn't, or is it the other way
> around?
>
> -Will
>
>

[SPAM]BGP Issue with L3?

[Dennis Burgess]

Doing a looking glass from the locally connected BGP peer for AS 16843,
they are receiving it, the top path, but showing it received-only, and
they want to use the "prepended" Path. The rest of L3, outside the local
peer looking glass, i.e. the rest of the planet does not even show this
path ?  Thoughts suggestions?

 

Dennis

 

Paths: (3 available, best #3)

  23077 174 7843 11427 16843, (received-only)

  AS-path translation: { SUNCOM COGENT ADELPHIA SCRR-11427
NORTHEAST-COMNET }

WIRELESS-ME.car1.Houston1 from WIRELESS-ME.car1.Houston1
(8.24.196.1)

  Origin IGP, localpref 100, valid, external

  Community: 174:21000 174:22013

  3549 3491 7459 16843 16843 16843 16843 16843 16843 16843

  AS-path translation: { GBLX CAIS-ASN THRIFTYCALL NORTHEAST-COMNET
NORTHEAST-COMNET NORTHEAST-COMNET NORTHEAST-COMNET NORTHEAST-COMNET
NORTHEAST-COMNET NORTHEAST-COMNET }

edge4.Dallas3 (metric 3827)

  Origin IGP, metric 10, localpref 88, valid, internal

  Community: North_America  Lclprf_86 United_States Level3_Peer
Dallas 3491:200 3549:300 3549:4292 3549:30840

  Originator: edge4.Dallas3

  3549 3491 7459 16843 16843 16843 16843 16843 16843 16843

  AS-path translation: { GBLX CAIS-ASN THRIFTYCALL NORTHEAST-COMNET
NORTHEAST-COMNET NORTHEAST-COMNET NORTHEAST-COMNET NORTHEAST-COMNET
NORTHEAST-COMNET NORTHEAST-COMNET }

edge4.Dallas3 (metric 3827)

  Origin IGP, metric 10, localpref 88, valid, internal, best

  Community: North_America  Lclprf_86 United_States Level3_Peer
Dallas 3491:200 3549:300 3549:4292 3549:30840

  Originator: edge4.Dallas3

 

Re: The End-To-End Internet (was Re: Blocking MX query)

[Nick Hilliard]

On 09/09/2012 23:24, Masataka Ohta wrote:
> Oliver wrote:
>> Just because something is documented in RFC does not automatically make it a
>> standard, nor does it necessarily make anyone care.
> 
> That's not a valid argument against text in the RFC proof read by
> the RFC editor as the evidence of established terminology of the
> Internet community.

you may want to read rfc 1796, and then retract what you said because it
sounds silly.

Nick