On 29 Dec 2009, at 17:19, Jared Mauch wrote:
> I've watched BCPs be diluted at various companies due to market pressures.
> $major_provider did not require me to register my routes, why should I have
> to do that in order to give you $X MRC for the next 12-24-36 months?
[...]
> Honestly, I wis
On Dec 29, 2009, at 5:47 PM, Randy Bush wrote:
None of us knows precisely what we're going to absolutely
require, or
merely want/prefer, tomorrow or the next day, much less a year or
two
from now. Unless, of course, we choose to optimize (constrain)
functionality so tightly around what we w
On Dec 29, 2009, at 6:15 PM, Michael Thomas wrote:
> That and building out
> separate and unequal networks pretty much sucks?
It does create job preservation in old-school telcos, like T.
- Jared
Randy Bush wrote:
Totally out of the box, but here goes: why don't we run the entire
Internet management plane "out of band"
tread caefully. we have experienced (and some continue to experience)
non-linear expansion of management, control, and stability problems when
layers are non-congru
>>> None of us knows precisely what we're going to absolutely require, or
>>> merely want/prefer, tomorrow or the next day, much less a year or two
>>> from now. Unless, of course, we choose to optimize (constrain)
>>> functionality so tightly around what we want/need today that the
>>> prospect of
On Tue, Dec 29, 2009 at 5:22 PM, Randy Bush wrote:
>> None of us knows precisely what we're going to absolutely require, or
>> merely want/prefer, tomorrow or the next day, much less a year or two
>> from now. Unless, of course, we choose to optimize (constrain)
>> functionality so tightly around
> None of us knows precisely what we're going to absolutely require, or
> merely want/prefer, tomorrow or the next day, much less a year or two
> from now. Unless, of course, we choose to optimize (constrain)
> functionality so tightly around what we want/need today that the
> prospect of getting a
> Totally out of the box, but here goes: why don't we run the entire
> Internet management plane "out of band"
tread caefully. we have experienced (and some continue to experience)
non-linear expansion of management, control, and stability problems when
layers are non-congruent.
randy
On 29/12/2009 21:10, Joe Greco wrote:
> How do you offer a "cheaper" level of
> (let's say) Web-only Internet access, when the support costs will be
> higher? Where's the value? What's the business plan? Where's the profit
> in that?
As an unrelated footnote, these are questions which will beco
> Joe wrote:
>
> >I am still failing to see why what you're talking about cannot be done
> >with today's technology.
> >
> >And if it can be done with today's technology, and isn't being done with
> >it, either that's a business opportunity for you, or it says something
> >about the model.
>
> T
> My $.02 or so - This "widespread castration" would force application
> developers to jump through the same NAT-traversal hoops all over again,
> adding more code-bloat / operational overhead and stifling innovation.
> Naturally, once created, this lower-class of internet user would probably
> bec
On Dec 29, 2009, at 12:59 PM, Dan White wrote:
On 29/12/09 12:20 -0500, Sachs, Marcus Hans (Marc) wrote:
Better than the typical "block outbound 25" filtering we do now. In
fact, in a perfect world ISPs would offer residential customers
"reduced
experience" versions of castration that decr
On Dec 29, 2009, at 7:08 AM, Steven Bellovin wrote:
> On Dec 29, 2009, at 9:29 AM, Sachs, Marcus Hans (Marc) wrote:
>> Totally out of the box, but here goes: why don't we run the entire Internet
>> management plane "out of band" so that customers have minimal ability to
>> interact with routing
Marc,
I don't think that's entirely true.
I have in previously run networks that remarked all precedence on inbound
traffic at the borders to particular values (mostly zero except where policy
dictated other) and then accepted the precedence values internally for
priority control.
Customers were
Sorry, your original query got lost behind the smoke of my out-of-the-box
musings.
My biggest quarrel with any type of IP precedence is that anybody along the
chain can set or reset these bits. There is no assurance that a packet's
priority will remain at the level set by the originator unless
On 29/12/09 12:20 -0500, Sachs, Marcus Hans (Marc) wrote:
Better than the typical "block outbound 25" filtering we do now. In
fact, in a perfect world ISPs would offer residential customers "reduced
experience" versions of castration that decrease the cost along with
decreasing what you have acc
Experts,
my inquiry was very specific and bounded to the following assumptions:
- in-band management
- not possible to filter customer traffic, certainly not for somebody
else's customer.
- IP
In this case diffserv can help prioritize management plane traffic over
user traffic. To do that only ipp
I actually proposed this (bounced it off Paul Mockapetris and Dave
Roberts at the time), and we did it for our internal routing in the
co-lo/hosted apps, when I was CTO at American Digital Network
(1996-1998). Basically, SNMP and our IGPs as well as IBGP rode a totally
private RFC 1918 network that
Joe wrote:
>I am still failing to see why what you're talking about cannot be done
>with today's technology.
>
>And if it can be done with today's technology, and isn't being done with
>it, either that's a business opportunity for you, or it says something
>about the model.
The later. It can be
Valdis said:
>The gene pool needed some chlorine anyhow, but this is a creative
approach. :)
>
>But seriously - would this be significantly different than the model
that
>many ISPs already use, where "consumer" connections get port 25
blocked, no
>servers allowed, etc, and "business grade" skip th
On Dec 29, 2009, at 11:43 AM, Sachs, Marcus Hans (Marc) wrote:
> Yes, taking away the mechanisms will result in a "castrated" Internet
> experience for the clueful ones which is why I don't think this can be a
> one-size-fits-all model like the hotels try to do. Imagine a residential ISP
> th
> -Original Message-
> From: Sachs, Marcus Hans (Marc) [mailto:marcus.sa...@verizon.com]
> Sent: Tuesday, December 29, 2009 11:43
> To: Joe Greco
> Cc: NANOG list
> Subject: RE: ip-precedence for management traffic
>
> Joe wrote:
>
> >Getting back to the OP's message, I keep having these
> Joe wrote:
> >Getting back to the OP's message, I keep having these visions of the
> >castrated "Internet" access some hotels provide. You know the ones.
> >The ones where everything goes through a Web proxy and you're forced
> >to have IE6 as a browser. For some people, who just want to log on
On Tue, 29 Dec 2009 11:43:25 EST, "Sachs, Marcus Hans (Marc)" said:
> one-size-fits-all model like the hotels try to do. Imagine a
> residential ISP that offers castration at a lower price point than what
> is currently charged for monthly "raw" access.
The gene pool needed some chlorine anyhow,
Joe wrote:
>Getting back to the OP's message, I keep having these visions of the
>castrated "Internet" access some hotels provide. You know the ones.
>The ones where everything goes through a Web proxy and you're forced
>to have IE6 as a browser. For some people, who just want to log on
>to Yah
On Tue, 29 Dec 2009 10:00:57 CST, Joe Greco said:
> Do we really want to spread that sort of model to the rest of the
> Internet? All it really encourages is for more and more things to
> be ported to HTTP, including, amusingly, management of devices...
I can remember at one time, some of the sam
> Nope, not joking. Quite serious about this.
>
> Glad we agree about the residential customers. Perhaps that's the first
> place to start and could generate some interesting lessons.
>
> Properly dual-homed customers are what I'd lump into the "clueful" category
> so they are not the ones I'
Nope, not joking. Quite serious about this.
Glad we agree about the residential customers. Perhaps that's the first place
to start and could generate some interesting lessons.
Properly dual-homed customers are what I'd lump into the "clueful" category so
they are not the ones I'm talking abou
On Tue, Dec 29, 2009 at 10:08 AM, Steven Bellovin wrote:
>
> On Dec 29, 2009, at 9:29 AM, Sachs, Marcus Hans (Marc) wrote:
>
>> Totally out of the box, but here goes: why don't we run the entire Internet
>> management plane "out of band" so that customers have minimal ability to
>> interact wit
On Dec 29, 2009, at 9:29 AM, Sachs, Marcus Hans (Marc) wrote:
> Totally out of the box, but here goes: why don't we run the entire Internet
> management plane "out of band" so that customers have minimal ability to
> interact with routing updates, layer 3/4 protocols, DNS, etc.? I don't mean
Totally out of the box, but here goes: why don't we run the entire Internet
management plane "out of band" so that customers have minimal ability to
interact with routing updates, layer 3/4 protocols, DNS, etc.? I don't mean
100% exclusion for all customers, but for the average Joe-customer
(
On Tue, 29 Dec 2009, Deric Kwok wrote:
Hi all
I got the following message.
UDP: bad checksum. From 67.204.26.203:1054 to 66.49.0.97:55290 ulen 43
UDP: short packet: From 67.55.92.141:23801 30368/46 to 66.49.0.0:24617
What is this meaning?
Possibly a switch somewhere between the src and dst
One note on this :-)..
Some time ago, a friend of mine worked in a carrier that had dialup modems for
out-of-band access ('lights-out, end-of-world' recovery)
They kept the practice in a new NGN Class4/5 replacement..
Detail, the dial-up line went over the NGN..
On Dec 29, 2009, at 6
Send along a capture when you get the chance.
David
On Tue, Dec 29, 2009 at 4:56 AM, Deric Kwok wrote:
> Hi all
>
> I got the following message.
>
> UDP: bad checksum. From 67.204.26.203:1054 to 66.49.0.97:55290 ulen 43
> UDP: short packet: From 67.55.92.141:23801 30368/46 to 66.49.0.0:24617
>
Hi all
I got the following message.
UDP: bad checksum. From 67.204.26.203:1054 to 66.49.0.97:55290 ulen 43
UDP: short packet: From 67.55.92.141:23801 30368/46 to 66.49.0.0:24617
What is this meaning?
Which network device is problem?
Why it happens in the network?
Thank you
On Dec 29, 2009, at 2:07 AM, Dobbins, Roland wrote:
>
> On Dec 29, 2009, at 6:02 PM, Luca Tosolini wrote:
>
>> this leaves out only ipp 7 for management traffic, on the premise that
>> routing and management should not share the same queue and resources.
>
> Management-plane traffic shoul
On Dec 29, 2009, at 6:02 PM, Luca Tosolini wrote:
> this leaves out only ipp 7 for management traffic, on the premise that
> routing and management should not share the same queue and resources.
Management-plane traffic should be sent/received via your DCN/OOB network, so
that it's not com
Experts,
what is the general opinion of using ipp 7 'network control' for
management traffic like: telnet ssh snmp .
The idea is that ipp 0 1 2 3 4 5 are used for user traffic
ipp = 6 is used by default by routing protocols like BGP, OSPF, LDP ...
this leaves out only ipp 7 for management tra
38 matches
Mail list logo
