On Wed, Feb 08, 2006 at 04:37:31AM +, Christopher L. Morrow wrote:
I had thought Josh's paper (or maybe not josh, whomever it was) said
something along the lines of:
1) if more than one announcement prefer 'longer term', 'older', 'more
usual' route
2) if only one route take it and run!
Here is what we propose in PGBGP. If you have a more specific route
and its AS Path does not contain any of the less specific route's
origins, then ignore it for a day and keep routing to the less
specific origin. If it's legitimate the less specific origin should
forward the data on for the
Martin Hannigan wrote:
My answer, in short, was to say that I see it as more of an enterprise
play because it's a managed service and the hardest part of
provisioning is typically the order cycle.
If you are an ISP, you are theoretically multi homed by definition
and your providers are going
On Tue, 7 Feb 2006, Nick Feamster wrote:
As an aside, another question occurred to me about delaying unusual
announcements. Boeing Connexion offers another example of unorthodox
prefix announcements. Wouldn't the tactic of delaying unusual
announcements would cause problems for this
At 11:27 PM 2/7/2006, Nick Feamster wrote:
Martin Hannigan wrote:
My answer, in short, was to say that I see it as more of an enterprise
play because it's a managed service and the hardest part of
provisioning is typically the order cycle.
If you are an ISP, you are theoretically multi homed
Chris has it!
And to be clear, we only require a slow (1 day) provider changeover in
the case that you want to announce your old provider's sub-prefix at a
new provider. For instance, if you are an ATT customer using a 12/8
sub-prefix and change providers but keep the prefix, the prefix will
If an IRR suffers from bit-rot, then I don't consider
it to be well-operated and therefore it cannot be
considered to be part of a well-operated network of
IRRs.
honestly I'm not a fan of IRR's, so don't pay attention to them, but...
is
the IRR 'not well operated' or is the data
Other networks have no such incentive, since their transit providers
and peers either build their filters in other ways, or don't filter
at all.
There is nothing wrong with building your filter in
some other way, however, that does not mean that you
cannot validate your filters against the
At 02:05 AM 2/6/2006, Nick Feamster wrote:
Martin Hannigan wrote:
[ SNIP ]
If you are changing providers, which takes
awhile anyway,
That process seems to be getting quicker:
http://www.equinix.com/prod_serv/network/ed.htm
NOT an ISP product.
Independent of ED, one should be
On Fri, Feb 03, 2006 at 02:15:45PM -0500, Nick Feamster wrote:
[snip]
This is a losing proposition. The data in the IRR, CA, or any mechanism
that is updated out-of-band from the protocol itself will inherently be
out-of-sync.
Provisioning systems are out of synch with the protocol, but
[ SNIP ]
If you are changing providers, which takes
awhile anyway,
That process seems to be getting quicker:
http://www.equinix.com/prod_serv/network/ed.htm
NOT an ISP product.
-M
Martin Hannigan(c) 617-388-2663
Renesys Corporation
Martin Hannigan wrote:
[ SNIP ]
If you are changing providers, which takes
awhile anyway,
That process seems to be getting quicker:
http://www.equinix.com/prod_serv/network/ed.htm
NOT an ISP product.
Independent of ED, one should be cautious when designing routing
protocols based
At 02:05 AM 2/6/2006, Nick Feamster wrote:
Martin Hannigan wrote:
[ SNIP ]
If you are changing providers, which takes
awhile anyway,
That process seems to be getting quicker:
http://www.equinix.com/prod_serv/network/ed.htm
NOT an ISP product.
Independent of ED, one should be cautious
On Mon, 30 Jan 2006 [EMAIL PROTECTED] wrote:
Wouldn't a well-operated network of IRRs used by 95% of
network operators be able to meet all three of your
requirements?
We have such a database (used by Verio and others), but the Panix
incident
happened anyway due to bit rot.
On Fri, 3 Feb 2006, Josh Karlin wrote:
Our primary concern is with keeping BGP stable until its replacement
(e.g. sBGP) is ready for deployment.
veering off course for a tick: I wonder how well sbgp/sobgp will behave
in a world of 1million routes in the DFZ? 5 million? 10? 20?...
Someone
On 4-Feb-2006, at 15:21, Christopher L. Morrow wrote:
honestly I'm not a fan of IRR's, so don't pay attention to them,
but... is
the IRR 'not well operated' or is the data stale because the
'users' of
the IRR are 'not well operated' ?
The data ought to be maintained by the people to
Josh Karlin wrote:
Hasn't that been said for years? Wouldn't perfect IRRs be great? I
couldn't agree more. But in the meanwhile, why not protect your own
ISP by delaying possible misconfigurations.Our proposed delay does
*not* affect reachability, if the only route left is suspicious, it
Wouldn't a well-operated network of IRRs used by 95% of
network operators be able to meet all three of your
requirements?
-certified prefix ownership
-certified AS path ownership
-dynamic changes to the above two items
It seems to me that most of the pieces needed to do
this already exist.
Hasn't that been said for years? Wouldn't perfect IRRs be great? I
couldn't agree more. But in the meanwhile, why not protect your own
ISP by delaying possible misconfigurations.Our proposed delay does
*not* affect reachability, if the only route left is suspicious, it
will be
On Jan 30, 2006, at 5:02 AM, Richard A Steenbergen wrote:
On Mon, Jan 30, 2006 at 09:48:13AM +,
[EMAIL PROTECTED] wrote:
Wouldn't a well-operated network of IRRs used by 95% of
network operators be able to meet all three of your
requirements?
We have such a database (used by Verio
Wouldn't a well-operated network of IRRs used by 95% of
network operators be able to meet all three of your
requirements?
We have such a database (used by Verio and others), but the Panix
incident
happened anyway due to bit rot. We've got to find a way to fix the
layer 8
problems
Perhaps people should stop trying to have these
operational discussions in the IETF and take the
discussions to NANOG where network operators gather.
We have tried, of course; see, for example, NANOG 28 (Salt Lake City).
There was no more consensus at NANOG than in the IETF...
One attempt
On Mon, Jan 30, 2006 at 09:48:13AM +, [EMAIL PROTECTED] wrote:
Wouldn't a well-operated network of IRRs used by 95% of
network operators be able to meet all three of your
requirements?
We have such a database (used by Verio and others), but the Panix
incident
happened
Wouldn't a well-operated network of IRRs used by 95% of
network operators be able to meet all three of your
requirements?
Maybe I missed something, but didn't Verio say the prefix was in
their internal registry, and that's why it was accepted.
IOW: It didn't solve this problem. So
the scheme that josh karlin has been advocating in pretty good bgp
involved only supressing a doubtful announcement when you have a
better, more trusted announcement.
Not a doubtful announcement, a novel announcement. Not a better
announcement, a more usual announcement. The trust part, like
sandy,
On Mon, Jan 30, 2006 at 08:29:45AM -0500, [EMAIL PROTECTED] wrote:
the scheme that josh karlin has been advocating in pretty good bgp
involved only supressing a doubtful announcement when you have a
better, more trusted announcement.
Not a doubtful announcement, a novel
In message [EMAIL PROTECTED]
.com, [EMAIL PROTECTED] writes:
certified validation of prefix ownership (and path, as has been
pointed out) would be great. it's clearly a laudable goal and seemed
like the right way to go. but right now, no one is doing it. the
rfcs that's i've found have
All these explanations can only go so far as to show that ConEd
and its upstreams may have had these prefixes as something that is
allowed (due to previous transit relationships) to be annnounced.
However presumably all these were transit arrangements with ConEd
and ip blocks would have
On Fri, Jan 27, 2006 at 04:36:28AM -0800, Randy Bush wrote:
what I saw by going through the diffs, etc.. that I have
available to me is that the prefix was registered to be announced
by our customer and hence made it into our automatic IRR filters.
i.e., the 'error' was intended, and
seems to me that certified validation of prefix ownership and as
path are the only real way out of these problems that does not
teach us the 42 reasons we use a *dynamic* protocol.
Wouldn't a well-operated network of IRRs used by 95% of
network operators be able to meet all three of your
Wouldn't a well-operated network of IRRs used by 95% of
network operators be able to meet all three of your
requirements?
-certified prefix ownership
-certified AS path ownership
-dynamic changes to the above two items
It seems to me that most of the pieces needed to do
this already
randy, all,
On Fri, Jan 27, 2006 at 04:36:28AM -0800, Randy Bush wrote:
what I saw by going through the diffs, etc.. that I have
available to me is that the prefix was registered to be announced
by our customer and hence made it into our automatic IRR filters.
i.e., the 'error' was
On Fri, Jan 27, 2006 at 10:42:11AM -0500, Joe Abley wrote:
On 27-Jan-2006, at 07:51, [EMAIL PROTECTED] wrote:
perhaps you mean certified validation of prefix origin
and path.
In the absense of path valdiation, a method of determining the real
origin of a prefix is also
certified validation of prefix ownership (and path, as has been
pointed out) would be great. it's clearly a laudable goal and seemed
like the right way to go. but right now, no one is doing it. the
rfcs that's i've found have all expired. and the conversation about
it has reached the
On 27-Jan-2006, at 11:12, [EMAIL PROTECTED] wrote:
but by definition, the right-most entry is the prefix origin...
Suppose AS 9327 decides to originate 198.32.6.0/24, but prepends 4555
to the AS_PATH as it does so. Suppose 9327's uses a transit provider
which builds prefix
Thus spake [EMAIL PROTECTED]
seems to me that certified validation of prefix ownership and as
path are the only real way out of these problems that does not
teach us the 42 reasons we use a *dynamic* protocol.
Wouldn't a well-operated network of IRRs used by 95% of
network operators be able
On Jan 27, 2006, at 8:29 AM, [EMAIL PROTECTED] wrote:
seems to me that certified validation of prefix ownership and as
path are the only real way out of these problems that does not
teach us the 42 reasons we use a *dynamic* protocol.
Wouldn't a well-operated network of IRRs used by 95% of
On Jan 27, 2006, at 11:39 AM, Joe Abley wrote:
On 27-Jan-2006, at 11:12, [EMAIL PROTECTED] wrote:
but by definition, the right-most entry is the prefix origin...
Suppose AS 9327 decides to originate 198.32.6.0/24, but prepends
4555 to the AS_PATH as it does so. Suppose 9327's
On Fri, Jan 27, 2006 at 11:39:27AM -0500, Joe Abley wrote:
On 27-Jan-2006, at 11:12, [EMAIL PROTECTED] wrote:
but by definition, the right-most entry is the prefix origin...
Suppose AS 9327 decides to originate 198.32.6.0/24, but prepends 4555
to the AS_PATH as it does so.
On 27-Jan-2006, at 11:54, Patrick W. Gilmore wrote:
On Jan 27, 2006, at 8:29 AM, [EMAIL PROTECTED] wrote:
seems to me that certified validation of prefix ownership and as
path are the only real way out of these problems that does not
teach us the 42 reasons we use a *dynamic* protocol.
On Jan 27, 2006, at 12:57 PM, Joe Abley wrote:
On 27-Jan-2006, at 11:54, Patrick W. Gilmore wrote:
On Jan 27, 2006, at 8:29 AM, [EMAIL PROTECTED] wrote:
seems to me that certified validation of prefix ownership and as
path are the only real way out of these problems that does not
teach us
Todd Underwood wrote:
you're probably right (as usual). but it seems that if you delay
acceptance of announcements with novel origination patterns, you don't
harm very many legitimate uses. in particular, ASes changing
upstreams won't be harmed at all. people moving their prefix to a new
ISP
Todd Underwood wrote:
seems to me that certified validation of prefix ownership and as
path are the only real way out of these problems that does not
teach us the 42 reasons we use a *dynamic* protocol.
certified validation of prefix ownership (and path, as has been
pointed out) would be
Michael.Dillon wrote:
Writing RFCs is a fine way to document operational
best practices, but it is not a good way to work out
joint operational practices.
Seems to me that operational problem solving works
better when the problem is not thrown into the laps
of the protocol designers.
If the
This is great for the planned changes, but real-time changes to
respond to Internet dynamics won't work well with such delays. If you
are multi-homed to provide a backup, you would like for it to respond
more quickly than 4-72 hours, I'll bet. So if you have PI space but not
your own AS,
In terms of the larger question
ConEd Communications was recently acquired by RCN. I'm not sure if the
transaction has formally closed. I suspect there are serious transition
issues occurring. Financial Stability, Employee Churn, and Ownership
are, unfortunately, tough things to factor into
Daniel Golding [EMAIL PROTECTED] wrote:
ConEd Communications was recently acquired by RCN. I'm not sure if the
transaction has formally closed. I suspect there are serious transition
issues occurring. Financial Stability, Employee Churn, and Ownership
are, unfortunately, tough things to factor
Steven, all,
On Wed, Jan 25, 2006 at 03:04:30PM -0500, Steven M. Bellovin wrote:
It's now been 2.5 business days since Panix was taken out. Do we know
what the root cause was? It's hard to engineer a solution until we
know what the problem was.
I keep hearing that Con Ed Comm was
Dislcaimer: I work for AS2914
On Thu, Jan 26, 2006 at 02:39:59PM -0500, Todd Underwood wrote:
Another set of approaches has been to look at alternate methods of
building filters, taking into account more information about history
of routing announcements and dampening or refusing to accept
The noise of origin changes is fairly heavy, somewhere in the low
hundreds of alerts per day given a 3 day history window. Supposing a
falsely originated route was delayed, what is the chance of identifying
and fixing it before the end of the delay period? Do operators
commonly catch
On Thu, Jan 26, 2006 at 04:22:29PM -0700, Josh Karlin wrote:
The noise of origin changes is fairly heavy, somewhere in the low
hundreds of alerts per day given a 3 day history window. Supposing a
falsely originated route was delayed, what is the chance of identifying
and fixing it before the
I unfortunately don't have answers to those questions, but you've
piqued my interest so I will try to look into it within the next
couple of days.
Josh
On 1/26/06, Jared Mauch [EMAIL PROTECTED] wrote:
On Thu, Jan 26, 2006 at 04:22:29PM -0700, Josh Karlin wrote:
The noise of origin changes
jared,
i may have missed the answer to my question. but, as verio was
the upstream, and verio is known to use the irr to filter, could
you tell us why that approach seemed not to suffice in this case?
randy
On Thu, Jan 26, 2006 at 05:41:10PM -0800, Randy Bush wrote:
jared,
i may have missed the answer to my question. but, as verio was
the upstream, and verio is known to use the irr to filter, could
you tell us why that approach seemed not to suffice in this case?
Sure, what I saw by
It's now been 2.5 business days since Panix was taken out. Do we know
what the root cause was? It's hard to engineer a solution until we
know what the problem was.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
On Wed, 25 Jan 2006, Steven M. Bellovin wrote:
It's now been 2.5 business days since Panix was taken out. Do we know
what the root cause was? It's hard to engineer a solution until we
know what the problem was.
Is it really that hard to engineer this solution? We do have several of
them
On Wed, 25 Jan 2006, william(at)elan.net wrote:
On Wed, 25 Jan 2006, Steven M. Bellovin wrote:
It's now been 2.5 business days since Panix was taken out. Do we know
what the root cause was? It's hard to engineer a solution until we
know what the problem was.
Is it really that hard to
On Thu, 26 Jan 2006 07:54:30 +0200, Pekka Savola said:
It'd be darn difficult to engineer a solution that would end up being
deployed in any reasonable time if we don't know the requirements
first.
Fortunately, when we know the requirements and engineer a solution, deployment
is
On Thu, 26 Jan 2006, [EMAIL PROTECTED] wrote:
In other words - what is the business case for deploying this proposed
solution? I may be able to get things deployed at $WORK by arguing that
it's The Right Thing To Do, but at most shops an ROI calculation needs
to be attached to get movement
In message [EMAIL PROTECTED], Pekka Savola writes:
On Thu, 26 Jan 2006, [EMAIL PROTECTED] wrote:
In other words - what is the business case for deploying this proposed
solution? I may be able to get things deployed at $WORK by arguing that
it's The Right Thing To Do, but at most shops an ROI
60 matches
Mail list logo
