Re: IPv6 news

[Suresh Ramasubramanian]

On 24/10/05, Alexei Roudnev <[EMAIL PROTECTED]> wrote:
>
> We do not think, that _it wil be IPv6_. IPv6 is a good example of _second_
> system, and do not looks as _succesfull_ for now.
> And it is not definitely _LAST PROTOCOL_.
>

enter jim fleming (or those chinese guys, more recently) with ipv9

srs

ADSL multiplexing (bonding)

[Gregory Edigarov]

Hello List,

Need an advice on what type of equipment/manufacturer would one use to 
multiplex 2 or 4 ADSL lines?
E.g we need to get 2 ADSL line to act as one. Something like Etherchanel 
with Ciscos.

Any advise?

Thanks a lot in advance.

--
With best regards,
GRED-RIPE

What is multihoming was (design of a real routing v. endpoint id seperation)

[Michael . Dillon]

> > the market wouldn't
> > feel the need to have to dual home.

> the internet model is to expect and route around failure.

Seems to me that there is some confusion over the meaning
of "multihoming". We seem to assume that it means BGP multihoming
wherein a network is connected to multiple ASes and uses BGP
to manage traffic flows. 

Other people use this term in very different ways. To some people
it means using having multiple IP addresses bound to a single
network interface. To others it means multiple websites on one
server.

And to many consumers of network access it is a synonym for
redundancy or resiliency or something like that. BGP multihoming
is not the only way to satisfy the consumers of network access
and design a solution in which failure is expected and it is
possible for the customer to route around failure.

A single tier-2 ISP who uses BGP multihoming with several
tier 1 ISPs can provide "multihoming" to it's customers 
without BGP. For instance, if this tier-2 has two PoPs
in a city and peering links exist at both PoPs and they
sell a resilient access service where the customer has
two links, one to each PoP, then it is possible to route
around many failures. This is probably sufficient for most
people and if the tier-2 provider takes this service seriously
they can engineer things to make total network collapse exteremely
unlikely.

Another way in which consumer's could be "multihomed" would be 
to have their single access link going to an Internet exchange
where there is a choice of providers. If one provider's network
fails, they could phone up another provider at the exchange and
have a cross-connect moved to restore connectivity in an hour or
so. This will satisfy many people.

Of course there are many variations on the above theme. This is
an issue with multiple solutions, some of which will be superior 
to BGP multihoming. It's not a simple black or white scenario.
And being a tier-1 transit-free provider is not all good. It may
give some people psychological comfort to think that they are in
the number 1 tier, but customers have good reason to see tier-1
transit-free status as a negative.

--Michael Dillon

Re: ADSL multiplexing (bonding)

[william(at)elan.net]

On Mon, 24 Oct 2005, Gregory Edigarov wrote:


Hello List,

Need an advice on what type of equipment/manufacturer would one use to 
multiplex 2 or 4 ADSL lines?
E.g we need to get 2 ADSL line to act as one. Something like Etherchanel 
with Ciscos.


Are all these DSLs parallel to each other from the same device on the
end-site to the same device on the provider side? If not are these at
least DSL lines provided by the same DSL provider with most likely ATM
that originates at DSL provider and end on end-user dsl line site? Are
the DSL lines exactly the same speed and configuration?

--
William Leibzon
Elan Networks
[EMAIL PROTECTED]

Re: ADSL multiplexing (bonding)

[Gregory Edigarov]

william(at)elan.net wrote:


On Mon, 24 Oct 2005, Gregory Edigarov wrote:


Hello List,

Need an advice on what type of equipment/manufacturer would one use 
to multiplex 2 or 4 ADSL lines?
E.g we need to get 2 ADSL line to act as one. Something like 
Etherchanel with Ciscos.



Are all these DSLs parallel to each other from the same device on the
end-site to the same device on the provider side? If not are these at
least DSL lines provided by the same DSL provider with most likely ATM
that originates at DSL provider and end on end-user dsl line site? Are
the DSL lines exactly the same speed and configuration?


Let's think I will answer "yes"  to the questions one at a time. :-)
I do not have the formal task description yet,  so I am  merely looking 
for opinions on options available,

so I could start  making decisions.

--
With best regards,
GRED-RIPE

Re: What is multihoming was (design of a real routing v. endpoint id seperation)

[Owen DeLong]

--On October 24, 2005 10:01:21 AM +0100 [EMAIL PROTECTED] wrote:




> the market wouldn't
> feel the need to have to dual home.



the internet model is to expect and route around failure.


Seems to me that there is some confusion over the meaning
of "multihoming". We seem to assume that it means BGP multihoming
wherein a network is connected to multiple ASes and uses BGP
to manage traffic flows.


As I understand it, the term multihoming in a network operations
context is defined as:

(A multihomed network is)
A network which is connected via multiple distinct
paths so as to eliminate or reduce the likelihood that a single
failure will significantly reduce reachability.

Note, this is independent of the protocols used, or, even of
whether or not what is being connected to is the internet.
So, it does not assume BGP.  It does not assume an AS.

Now, in the context of an ARIN or NANOG discussion, I would expect
to be able to add the following assertions to the term:

1.  The connections are to the internet.  A connection which
is not to the internet is of little operational
significance to NANOG, and, ARIN has very little to
do with multihoming in general, and, even less if it is
not related to the internet.

2.  The connections are likely to distinct ISPs, although, in
some cases, not necessarily so.  Certainly, if one is to
say one is addressing the issues of multihoming, then,
one must address both values for this variable.

3.  Most multihoming today is done using BGP, but, many other
solutions exist with various tradeoffs.  In V6, there is
currently only one known (BGP) and one proposed, but,
unimplemented (Shim6) solution under active consideration
by IETF. (this may be untrue, but, it seems to be the
common perception even if not reality).


Other people use this term in very different ways. To some people
it means using having multiple IP addresses bound to a single
network interface. To others it means multiple websites on one
server.


That is not multihoming.  That may be an implementation artifact
of some forms of multihoming (using the addresses assigned by
multiple providers ala Shim6 proposal), but, multiple addresses
on an interface do not necessarily imply multihoming.  In fact,
more commonly, that is virtual hosting.


And to many consumers of network access it is a synonym for
redundancy or resiliency or something like that. BGP multihoming
is not the only way to satisfy the consumers of network access
and design a solution in which failure is expected and it is
possible for the customer to route around failure.


It certainly is one component of a redundancy/resiliency solution.


A single tier-2 ISP who uses BGP multihoming with several
tier 1 ISPs can provide "multihoming" to it's customers
without BGP. For instance, if this tier-2 has two PoPs
in a city and peering links exist at both PoPs and they
sell a resilient access service where the customer has
two links, one to each PoP, then it is possible to route
around many failures. This is probably sufficient for most
people and if the tier-2 provider takes this service seriously
they can engineer things to make total network collapse exteremely
unlikely.


As long as you are willing to accept that a policy failure in
said Tier2 ISP could impact both pops simultaneously, and,
accept that single point of failure as a risk, then, yes,
it might meet some customers' needs. It will not meet all
customers' needs.


Another way in which consumer's could be "multihomed" would be
to have their single access link going to an Internet exchange
where there is a choice of providers. If one provider's network
fails, they could phone up another provider at the exchange and
have a cross-connect moved to restore connectivity in an hour or
so. This will satisfy many people.


Again, there are tradeoffs and risks to be balanced here as there
are multiple single points of failure inherent in such a
scenario.  However, at the IP level, such a network would, indeed
be multihomed.  The layer 1 and 2 issues not withstanding.


Of course there are many variations on the above theme. This is
an issue with multiple solutions, some of which will be superior
to BGP multihoming. It's not a simple black or white scenario.
And being a tier-1 transit-free provider is not all good. It may
give some people psychological comfort to think that they are in
the number 1 tier, but customers have good reason to see tier-1
transit-free status as a negative.


I'm not sure why you say some are superior to BGP multihoming.
I can see why some are more cost effective, easier, simpler
in some cases, or, possibly more hassle-free, but, the term
superior is simply impossible to define in this situation,
so, I'm unsure how you can categorize something as superior
when the term can't be defined sufficiently.

Owen


--
If this message was not signed with gpg key 0FE2AA3D, it'

Re: What is multihoming was (design of a real routing v. endpoint id seperation)

[Jeroen Massar]

On Mon, 2005-10-24 at 02:24 -0700, Owen DeLong wrote:

> 3.Most multihoming today is done using BGP, but, many other
>   solutions exist with various tradeoffs.  In V6, there is
>   currently only one known (BGP) and one proposed, but,
>   unimplemented (Shim6) solution under active consideration
>   by IETF. (this may be untrue, but, it seems to be the
>   common perception even if not reality).

As for "multihoming" in the sense that one wants redundancy, getting two
uplinks to the same ISP, or what I have done a couple of times already,
multiple tunnels between 2 sites (eg 2 local + 2 remote) and running
BGP/OSPF/RIP/VRRP/whatever using (private) ASN's and just providing a
default to the upstream network and them announcing their /48 works
perfectly fine.

The multihoming that people here seem to want though is the Provider
Independent one, and that sort of automatically implies some routing
method: read BGP.

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part

Re: ADSL multiplexing (bonding)

[william(at)elan.net]

On Mon, 24 Oct 2005, Gregory Edigarov wrote:


Let's think I will answer "yes"  to the questions one at a time. :-)
I do not have the formal task description yet,  so I am  merely looking for 
opinions on options available,

so I could start  making decisions.


If you have direct connection (multiple ones) between two routers using
L2 then upper layer protocols (which I'll assume to be ip) can be routed 
easily - simply add Loopback interface to each device and multiple static 
routes to the other side's loopback pointing to the interface itself. 
(think of the way you would do ip routing for parallel connections if you 
could not do ethercnannel but had multiple ethernet connections). You can 
also just use good routing protocol that can take care of load-balancing 
of traffic across parallel paths such as OSPF or IEGRP or possibly do MPLS

(although it is probably an overkill).

Now the question would be which device on the user side can be used
for terminating multiple dsl lines. From cisco you could use 2600
or 3600 router with several DSL WIC cards, see
 
http://www.cisco.com/en/US/products/hw/routers/ps221/products_data_sheet09186a0080088713.html)
Other manufactures may well have their own boxes and cards that do
the same. You can (I probabl would...) try to build your own box
with linux or bsd as both support range of dsl cards.

--
William Leibzon
Elan Networks
[EMAIL PROTECTED]

Re: design of a real routing v. endpoint id seperation

[Michael . Dillon]

> The way around it is to stop growing the DFZ routing table by the size
> of the Prefixes.  If customers could have PI addreses and the DFZ
> routing table was based, instead, on ASNs in such a way that customers
> could use their upstream's ASNs and not need their own, then, provider
> switch would be a change to the PI->ASN mapping and not affect the
> DFZ table at all.

One way to do this is for two ISPs to band together
in order that each ISP can sell half of a joint
multihoming service. Each ISP would set aside a
subset of their IP address space to be used by many
such multihomed customers. Each ISP would announce 
the subset from their neighbor's space which means
that there would be two new DFZ prefixes to cover
many multihomed customers. 

Each multihomed customer would run BGP using a private
AS number selected from a joint numbering plan. This
facilitates failover if one circuit goes down but
doesn't consume unneccesary public resources per customer.

This does require the two ISPs to maintain a strict
SLA on their interconnects in order to match the SLAs
on their customer contracts. The interconnect then
becomes more than "just" a peering connection, it also
becomes a mission critical service component.

Of course, the whole thing multihoming thing could
be outsourced to a 3rd party Internet exchange
operator with some creativity at both the technical
level and the business level. The IP address aggregate
would then belong to the exchange. More than 2 ISPs could
participate. Customers could move from one ISP to another
without changing addresses. The SLA on interconnects could
be managed by the exchange. Etc.

--Michael Dillon

Re: ADSL multiplexing (bonding)

[Pim van Pelt]

On Mon, Oct 24, 2005 at 12:22:59PM +0300, Gregory Edigarov wrote:
| Let's think I will answer "yes"  to the questions one at a time. :-)
| I do not have the formal task description yet,  so I am  merely looking 
| for opinions on options available,
| so I could start  making decisions.
We use multichannel ppp for some of our customers. They have a CPE
with two xDSL interfaces and both are transported to one chassis on
our (ISP) side. It's pretty straight forward.

groet,
Pim

-- 
Met vriendelijke groet,
BIT BV / Ing P.B. van Pelt
PBVP1-RIPE (PGPKEY-4DCA7E5E)

Re: multi homing pressure

[James]

On Sun, Oct 23, 2005 at 11:23:38PM -0700, Alexei Roudnev wrote:
> 
> It is not true. Many tier-2 ISP specializes in very ghigh quality Internet
> access, so mnasking problems of big ISP (who in reality never can provide
> high quality Internet at all). Good example - Internap.
> 

Masking "problems" of a big ISP and yet creating problems of their own.  Have
you seen completely multi-transited "tier2 networks" flapping hard core?

> So, it is not about tier-1 vs tier-2, it is about ISP specialized on cheap
> acvcess and ISP specialized on quality access. Is COGENT (for example only -
> I have nothing against them) tier-1 ISP - may be; are they high quality
> ISP - in NO WAY (they just provide bandwidth to nowhere without any clue).

Non-sense.

James

> 
> - Original Message - 
> From: "John Dupuy" <[EMAIL PROTECTED]>
> To: "Patrick W. Gilmore" <[EMAIL PROTECTED]>; 
> Sent: Wednesday, October 19, 2005 10:05 AM
> Subject: Re: multi homing pressure
> 
> 
> >
> >
> > >For the customer with an Internet "mission critical app", being tied
> > >to a Tier 2 has it's own set of problems, which might actually be
> > >worse than being tied to a Tier 1.
> >
> > The key word is "might". In fact, I would posit that a Tier 2 with
> multiply
> > redundant transit to all of the Tier 1s could theoretically have better
> > connectivity than an actual Tier 1. The Tier 2 transit provides
> flexibility
> > that the transit-free Tier 1s do not have. Just my opinion.
> >
> > Anyway, it has been my experience that most (but not all) of the customers
> > that want to "multihome" are _really_ wanting either: A. geographic/router
> > redundancy. or B. easy renumbering. Geographic redundancy can be done
> > within a single AS and IP block. They just don't know to ask it that way.
> > (And easy renumbering will eventually be solved with v6. Eventually.)
> >
> > The demand for multi-homing might not be as great as suspected.
> >
> > John
> >

Re: design of a real routing v. endpoint id seperation

[Owen DeLong]

--On October 24, 2005 10:44:31 AM +0100 [EMAIL PROTECTED] wrote:



One way to do this is for two ISPs to band together
in order that each ISP can sell half of a joint
multihoming service. Each ISP would set aside a
subset of their IP address space to be used by many
such multihomed customers. Each ISP would announce
the subset from their neighbor's space which means
that there would be two new DFZ prefixes to cover
many multihomed customers.


[snip...]

Except this completely disregards some customers concerns about having
provider independence and being able to change providers without
having a major financial disincentive to do so.  That _IS_ a real
business concern, no matter how much the IETF would like to pretend
it does not matter.

Owen



--
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.


pgpkFXpytrwxe.pgp
Description: PGP signature

Re: h-root-servers.net

[Sabri Berisha]

On Sun, Oct 23, 2005 at 04:07:03PM -0500, John Palmer (NANOG Acct) wrote:

Dear John,

> No, why don't you stop insulting people, Niels. You attack Peter because
> of his involvment in the Inclusive Namespace. FYI: Public root servers
> are online and available. Maybe the h-root ops should ask the P-R technical
> committee for assistance if they cannot keep their servers up.

Peter Dambier did post nonsense. In fact, it was total nonsense since
the AMS-IX is not present in any KPN datacentre, *and* it is impossible
for end-hosts to connect to the AMS-IX directly.

Niels his post was correctly and imho not insultive.

> Niels wrote:
> > * [EMAIL PROTECTED] (Peter Dambier) [Sun 23 Oct 2005, 22:34 CEST]:
> > >I know of one host here in germany who can see h.root-servers.net. That 
> > >host is living in a KPN data centre directly connected to Amterdam IX.
> > 
> > Peter, please stop posting nonsense.
> > 
> > -- Niels.

-- 
Sabri

please do not throw salami pizza away


pgpxHOjSsQzLK.pgp
Description: PGP signature

Re: What is multihoming was (design of a real routing v. endpoint id seperation)

[Jeroen Massar]

[re-ordered front-posting]

24 okt 2005 kl. 11.35 skrev Jeroen Massar:
> > The multihoming that people here seem to want though is the Provider
> > Independent one, and that sort of automatically implies some routing
> > method: read BGP.

On Mon, 2005-10-24 at 11:40 +0200, Peter Salanki wrote:
> Or shim6 :)

Of course, note that I wrote 'some routing method', which effectively
shim6 will be doing using some translations. Though I have to see it
first that it is up and running and people start using it, having good
hopes though but there are too many requirements and thus it won't fit
everybody the way they like it. Some people will simply require PI space
and nothing else... (*)

Greets,
 Jeroen


* = For IPv6 this means: be a LIR, plan 200 customers -> get it.



signature.asc
Description: This is a digitally signed message part

Re: ADSL multiplexing (bonding)

[Ryan O'Connell]

On 24/10/2005 10:22, Gregory Edigarov wrote:


william(at)elan.net wrote:


On Mon, 24 Oct 2005, Gregory Edigarov wrote:

Need an advice on what type of equipment/manufacturer would one use 
to multiplex 2 or 4 ADSL lines?
E.g we need to get 2 ADSL line to act as one. Something like 
Etherchanel with Ciscos.



Are all these DSLs parallel to each other from the same device on the
end-site to the same device on the provider side? If not are these at
least DSL lines provided by the same DSL provider with most likely ATM
that originates at DSL provider and end on end-user dsl line site? Are
the DSL lines exactly the same speed and configuration?


Let's think I will answer "yes"  to the questions one at a time. :-)
I do not have the formal task description yet,  so I am  merely 
looking for opinions on options available,

so I could start  making decisions.



Hardware-wise a Cisco 1700 will take two ADSL lines - if you want four 
lines you're looking at a 2600. I'm sure there are some but I'm not 
aware pesonally of any other vendors that supply CPE kit capable of 
handling multiple DSL lines.


Technology-wise, you can either use Multilink PPP or per-packet load 
balancing. Generally, you'll need the cooperation of the upstream ISP - 
although you can load balance upstream traffic using per-packet load 
balancing at your end, the ISP will mostly likely have unicast 
reverse-path turned on so will drop the packets. Obviously loadbalancing 
the downstream traffic requires a higher level of cooperation.


Multilink PPP is better as you get lower latency with the right settings 
plus less problems with out-of-order packets. However, I belive even 
with Multilink PPP you'll get *some* out of order packets which is quite 
cappable of totally crippling real-time applications such as VoIP.

Re: IPv6 news

[Michael . Dillon]

> > We do not think, that _it wil be IPv6_. IPv6 is a good example of 
_second_
> > system, and do not looks as _succesfull_ for now.
> > And it is not definitely _LAST PROTOCOL_.
> >
> 
> enter jim fleming (or those chinese guys, more recently) with ipv9

No, enter the National Science Foundation...
http://www.nsf.gov/cise/geni/

Jim Fleming's idea wasn't all that crazy and some people
are looking at similar partitioning schemes to make
IPv6 multihoming practical. The IPv9 idea from China
had nothing to do with IP, it was just a catchy marketing
name for yet another domain naming scheme like RealNames.

There really is serious, non-crazy research work going on
to make a better replacement for the Internet Protocol. 
And Dave Clark, author of this interesting document on 
Internet routing:
http://www.networksorcery.com/enp/ien/ien46.txt
has recently been going around giving talks on fundamental
re-architecting the Internet. At MIT he is a director
of the CFP which is getting NSF GENI grant money to
explore this:
http://cfp.mit.edu/groups/internet/internet.html

This is not the 1990's any more. ISO/CLNP has gone away.
ATM has been embraced in MPLS. PSTN is being embraced
in VoIP such as the British Telecom 21CN initiative.
What was crazy yesterday, is thinkable today.

In the end, IPv6 may be able to incorporate enough of
these new ideas to continue as the last protocol. But
we don't know that yet.

--Michael Dillon

Re: Level 3 RFO

[Florian Weimer]

* Daniel Roesen:

> On Sun, Oct 23, 2005 at 09:48:58PM +0200, Florian Weimer wrote:
>> This isn't the first time this has happened to an ISP. 8-(
>
> Indeed.
>
>> Are there any configuration tweaks which can locally confine such an
>> event?  Something like the hard prefix limit for BGP, perhaps.
>
> JunOS:
> set protocols ospf prefix-export-limit 
> set protocols isis level  prefix-export-limit 

Wouldn't an import limit be better?  If you've got a
almost-fully-meshed MPLS core, export limits won't really work, will
they?

In more traditional networks, I can imagine that it helps to confine
anomalies.  Has anybody tried that on a real network? 8-)

Recommendations for ISPs around the world

[Elmar K. Bins]

Dear colleagues,

I'm at a loss here. My current project is to find "good" transit providers
in those regions: South America, Eastern Europe, Africa, Asian-Pacific.

Requirements are simple:

  - good regional connectivity/peerings
  - fair reach to "mainland" Europe (London, Amsterdam, Frankfurt)
  - locations close to exchanges (so we can join there, too)

I'm thinking of using two transit ISPs per location (full BGP from our side,
of course).


I have considered MCI, BT Infonet, Verio, Reach, Sprint, for AP and/or Latin
America, but they of course all tell you that they are greatly interconnected.

For eastern europe I'm really at a loss, and Africa seems to lack regional
connectivity. All I can found is local stuff.

So, if anyone can give me a hand here, that would be greatly appreciated.

TIA,
Elmar.

--

"Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren."
  (PLemken, <[EMAIL PROTECTED]>)

--[ ELMI-RIPE ]---

Re: Recommendations for ISPs around the world

[Kim Onnel]

For Africa, check out Equant and BTOn 10/24/05, Elmar K. Bins <[EMAIL PROTECTED]> wrote:
Dear colleagues,I'm at a loss here. My current project is to find "good" transit providersin those regions: South America, Eastern Europe, Africa, Asian-Pacific.Requirements are simple:
  - good regional connectivity/peerings  - fair reach to "mainland" Europe (London, Amsterdam, Frankfurt)  - locations close to exchanges (so we can join there, too)I'm thinking of using two transit ISPs per location (full BGP from our side,
of course).I have considered MCI, BT Infonet, Verio, Reach, Sprint, for AP and/or LatinAmerica, but they of course all tell you that they are greatly interconnected.For eastern europe I'm really at a loss, and Africa seems to lack regional
connectivity. All I can found is local stuff.So, if anyone can give me a hand here, that would be greatly appreciated.TIA,Elmar.--"Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren."
  (PLemken,
<[EMAIL PROTECTED]>)--[ ELMI-RIPE ]---

Re: h-root-servers.net (Level3 Question)

[Peter Dambier]

Christopher L. Morrow wrote:


On Sun, 23 Oct 2005, Daniel Roesen wrote:


On Sun, Oct 23, 2005 at 11:59:15AM +0200, Peter Dambier wrote:


I means, here in germany we cannot see h.root-servers.net



Here is my traceroute to h.root-servers.net right now:


So, where do you see a problem related to L3/Cogent there? Your
traceroute hits DREN, the operator of h.root-servers.net.



agreed, looks like a dren 'issue' which MAY be a planned event? DREN
probably shouldn't filter traffic to/from h-root (aside from udp/53 |
tcp/53 traffic) no 'prefix-X not allowed to have access to h-root' sorts
of things) That said, they  MAY have done that, did someone (peter?) ask
them?



I did ask them.

Told me it was a firewall misshap.

Problem is solved now.


Thanks,

Peter and Karin Dambier

--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason

Re: h-root-servers.net

[Peter Dambier]

Sabri Berisha wrote:

On Sun, Oct 23, 2005 at 04:07:03PM -0500, John Palmer (NANOG Acct) wrote:

Peter Dambier did post nonsense. In fact, it was total nonsense since
the AMS-IX is not present in any KPN datacentre, *and* it is impossible
for end-hosts to connect to the AMS-IX directly.



Part of the traceroutes between me and the system I was talking of:

 6  da-ea1.DA.DE.net.DTAG.DE (62.153.179.54)  18.334 ms   22.725 ms   33.803 ms
 4  ams-e4.AMS.NL.net.DTAG.DE (62.154.15.2)  145.264 ms   152.212 ms   160.623 
ms

 5  amx-gw2.nl.dtag.de (195.69.145.211)  14.737 ms   13.115 ms   11.501 ms
 5  gb-2-0-0.amsix1.tcams.nl.easynet.net (195.69.144.38)  169.072 ms   176.623 
ms   184.463 ms

 4  213.201.252.133  19.577 ms   17.808 ms   16.000 ms
 6  213.201.252.10  194.043 ms   201.762 ms   209.455 ms

 3  217.195.244.142  21.561 ms   21.339 ms   20.145 ms
 7  Scylla (213.201.229.65)  156.335 ms   164.501 ms   171.735 ms

To my eyes it looks like the data is going through Amsterdam IX.

I did not say the host was connected to the IX. I said it was living in a
datacentre connected to Amsterdam IX.

The costumer pays for the ISP beeing present at Amsterdam IX.

If that is not the case please tell me, so they can get their money back.


I am sorry if I mixed up too computers one in the netherlands in an easynet
colocation with another one here in germany with KPN. Both could reach
h.root-servers.net

And this I found from the Amsterdam IX memberlist:

Name:
KPN Internet Solutions - AS286
AS Number: 286
URL: www.as286.net
Member since: 2002-10-14
Organisational contact: [EMAIL PROTECTED]
Peering contact: [EMAIL PROTECTED]
Peering policy: www.as286.net

So I guess that computer too is connect not via DTAG.DE but via
Amsterdam IX

I never claimed to be a routing guru. I you feel like splitting
hairs you are welcome.


Kind regards,
Peter and Karin Dambier


--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason

AfNOG and AfriNIC Joint Announcement: Meetings in May 2006

[Randy Bush]

AfNOG and AfriNIC Joint Announcement: Meetings in May 2006

7th AfNOG Meeting

AfriNIC-4 Meeting

The African Network Operators' Group (AfNOG) and the African Network
Information Centre (AfriNIC) are pleased to announce that the 7th AfNOG
Meeting and the AfriNIC-4 Meeting will be held Nairobi, Kenya, in May
2006.

About the entire event

AfNOG and AfriNIC are jointly organising a two-week event
that includes the AfNOG Workshop on Network Technology
(offering advanced training in a week-long hands-on workshop),
several half-day Tutorials, a one-day AfNOG meeting, and
a two-day AfriNIC meeting.  Further information about the
event may be found at  and
.

Timetable

AfNOG Workshop  7 - 12 May 2006 (Sunday - Friday)
AfNOG Tutorials 14 May 2006 (Sunday)
AfNOG Meeting   15 May 2006 (Monday)
AfriNIC Meeting 16 - 17 May 2006 (Tuesday - Wednesday)

Venue

The event will be held in Nairobi, Kenya.  The exact venue
has not yet been finalised.  Updated information will be
made available at  and
.

About AfNOG

AfNOG (see ) is a forum for cooperation
and the exchange of technical information between operators of
Internet-connected networks in Africa.  AfNOG has organised
an event like this one every year since 2000.

About AfriNIC

AfriNIC (see ) is a Regional Internet
Registry (RIR), responsible for the registration and allocation of
Internet number resources in Africa and parts of the Indian Ocean.

AfNOG Workshop on Network Technology

The AfNOG Workshop on Network Technology aims to offer advanced
training to people who are in the process of developing and
enhancing an Internet-connected network with regional and
international connectivity.  The target audience includes senior and
mid-level technical staff of commercial Internet service providers
(ISPs), academic networks, government networks, or NGO networks.

This workshop builds on the experience of previous AfNOG workshops
held annually from 2000 to 2005 in six different African countries,
and also the Internet Society's INET workshops, held annually from
1993 to 2000 at eight locations around the world.  The workshop's
instructors are an international team with many years of experience
operating large networks and teaching about network operations.

The workshop is divided into four parallel tracks:

Track E0 - Unix System Administration (in English), focused on
using a Unix-like operating system as a platform for
delivery of Internet services.

Track E1 - Scalable Internet Services (in English), focused
on the design and operation of email, web, and other
Internet services, in ways that can scale to handle
large numbers of end users.

Track E2 - Scalable Network Infrastructure (in English), focused
on the design and operation of networks using routers
and switches, in ways that can scale to handle large
numbers of interconnected sites.

Track F2 - Infrastructure  R=E9seaux  IP (en fran=E7ais),
similar to track E2, but given in French.

Further information and application forms are available at
.

AfNOG Tutorials

On 14 May 2006, the day before the AfNOG conference, several
tutorials will be offered.  Tutorials are typically half a day in
duration (4 hours including a break).

Tutorials take place in a classroom-style environment, and
may include a hands-on practical component.  Tutorials are
non-commercial in nature, and most are technically oriented.  They
are intended to highlight issues relating to technology already
deployed or soon to be deployed on networking and related services
provisioning for ISP operations.

People interested in presenting a tutorial are invited
to submit a proposal, following the instructions at
.

7th AfNOG Meeting

The 7th AfNOG meeting will be held in Nairobi, Kenya, on
15 May 2006.  AfNOG conferences provide a forum for the
coordination and dissemination of technical information related
to backbone/enterprise networking technologies and operational
practices.  The meetings are informal, with an emphasis on relevance
to current and future African backbone engineering practices.
Previous AfNOG conferences have attracted over 200 participants,
mainly consisting of engineering staff from network service
providers, managers from IT enterprises, and members of the research
and education community.

People interested i

RE: Level3 problems

[Gary Hale]

Hmmm ... I suppose I would prefer this community not be made an explicit
source of information for a reporter. Implicitly, if reporters must hang
off this thread, they should be able to discern impact from perspective
given here. However, if questions like the one(s) asked below became
"standard" on this thread, then soon the function of the group slants to
something other than a forum to aid (each other) in the proper
"management" of the affairs of Network Operators ... and may morph into
something far less useful.

No intention to "scare" ... 

-gh

-Original Message-
From: Alex Rubenstein [mailto:[EMAIL PROTECTED] 
Sent: Friday, October 21, 2005 1:43 PM
To: Gary Hale
Cc: [EMAIL PROTECTED]; nanog@merit.edu
Subject: RE: Level3 problems


Gary,

I understand your statement, but I am sure the gentleman below does not.

If you want a story to be done, so that the world can see how something 
like this can impact thousands of businesses, the best bet would be to 
help educate this guy so that he has something to write.

Are, were you trying to scare him off from doing a story?

Personally, I am quote fed up with the issues that the huge providers
have 
and cause, yet never have anyone document it, find out about it, or do 
anything about it. I laud this guys effort for actually trying to do his

job and expose something that needs to be exposed.

I am now putting on my level-3 bullet proof jacket, and will be looking 
over my shoulder for the next 3 NANOGs.





On Fri, 21 Oct 2005, Gary Hale wrote:

>
> Are you kidding?
>
> -gh
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of
> [EMAIL PROTECTED]
> Sent: Friday, October 21, 2005 11:03 AM
> To: nanog@merit.edu
> Subject: Re: Level3 problems
>
>
> I'm a reporter with InformationWeek magazine. I'm trying to get an
idea
> of the
> significance of this morning's outage. Has Level 3 communicated with
you
> about
> the cause of the outage? How greatly did the outage affect you or your
> customers? Was this an unusually large event?
> Thanks,
> [EMAIL PROTECTED]
>

-- 
Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben
Net Access Corporation, 800-NET-ME-36, http://www.nac.net

Re: h-root-servers.net

[Sabri Berisha]

On Mon, Oct 24, 2005 at 02:40:14PM +0200, Peter Dambier wrote:
> Sabri Berisha wrote:

Dear Peter,

> > Peter Dambier did post nonsense. In fact, it was total nonsense since
> > the AMS-IX is not present in any KPN datacentre, *and* it is impossible
> > for end-hosts to connect to the AMS-IX directly.
> 
> Part of the traceroutes between me and the system I was talking of:
> 
>  6  da-ea1.DA.DE.net.DTAG.DE (62.153.179.54)  18.334 ms   22.725 ms   
>  4  ams-e4.AMS.NL.net.DTAG.DE (62.154.15.2)  145.264 ms   152.212 ms   
>  5  amx-gw2.nl.dtag.de (195.69.145.211)  14.737 ms   13.115 ms   11.501 ms
>  5  gb-2-0-0.amsix1.tcams.nl.easynet.net (195.69.144.38)  169.072 ms   

> I did not say the host was connected to the IX. I said it was living in a
> datacentre connected to Amsterdam IX.

You said:

> I know of one host here in germany who can see h.root-servers.net.
> That host is living in a KPN data centre directly connected to Amterdam
> IX.

Your own traceroute clearly shows that your host is not directly
connected to the AMS-IX. Nor does the KPN datacenter it resides in. The
AMS-IX has 4 datacenters where members can place equipment which can be
directly connected to the AMS-IX:

- GlobalSwitch;
- Sara;
- Nikhef;
- Telecity2, Kuiperbergerweg;

Every statement otherwise is bogus, nonsense, crap or whatever term you
prefer to use for this.

-- 
Sabri

please do not throw salami pizza away

RE: Level3 problems

[Michael . Dillon]

> Hmmm ... I suppose I would prefer this community not be made an explicit
> source of information for a reporter. 

You're about 10 years too late. Reporters have been lurking
on the NANOG list for at least that long. Only the newbie
reporters post info requests to the lists. The pros send
private emails to list members or go to a NANOG meeting
and prowl the hallways.

Or did you somehow think that the Internet was a secret
network for the members of some private club?

--Michael Dillon

Customer view vs. operator view was:( h-root-servers.net)

[Michael . Dillon]

> > I know of one host here in germany who can see h.root-servers.net.
> > That host is living in a KPN data centre directly connected to 
Amterdam
> > IX.
> 
> Your own traceroute clearly shows that your host is not directly
> connected to the AMS-IX. Nor does the KPN datacenter it resides in. The
> AMS-IX has 4 datacenters where members can place equipment which can be
> directly connected to the AMS-IX:
> 
> - GlobalSwitch;
> - Sara;
> - Nikhef;
> - Telecity2, Kuiperbergerweg;
> 
> Every statement otherwise is bogus, nonsense, crap or whatever term you
> prefer to use for this.

This is a good example of a useless argument caused when one
person is speaking from a customer viewpoint and one customer
is speaking from an operator viewpoint.

Assume that there is an ISP X with a data center in Germany
and a colocated rack at Nikhef. They peer directly with many
other providers through AMS-IX from their Nikhef location.
Customer Q comes along and places a server in their data centre 
in Germany because he needs to serve his users both in Germany and
in his chain of hotels throughout Holland. His network people assure
him that the server is connected directly to AMS-IX because that
is what their traceroutes say.

Of course, we know better. We know that the server is connected
directly to ISP X and indirectly to AMS-IX because we are
used to being particular about which operator owns each
hop. But the customer Q doesn't see the hops in network X. 
To him, they are invisible because they are his HOME network.
Customers don't see themselves as network operators and therefore
they often think of their ISP's network as their own.

So who is right? Peter? Sabri? Both?
My opionion is that neither of them is right because they
both failed to understand what the real problem is and
they both failed to take the correct steps to solve the
problem. As it happens, this was a very, very basic
network issue which does not need to be discussed on
NANOG at all.

--Michael Dillon

Re: Customer view vs. operator view was:( h-root-servers.net)

[Sabri Berisha]

On Mon, Oct 24, 2005 at 03:06:35PM +0100, [EMAIL PROTECTED] wrote:

Dear Michael,

> This is a good example of a useless argument caused when one
> person is speaking from a customer viewpoint and one customer
> is speaking from an operator viewpoint.

Last time I checked, the O in [EU|NA|AFRI]NOG stands for 'operator'.
Niels made a perfectly valid point by saying that it is impossible for
an end-user to be connected to the AMS-IX and he was flamed for it. If
Peter Dambier has no clue about end-hosts vs intermediate systems, let
alone how to parse a traceroute with his grey mass, he needs to be educated.
Just as I needed many years ago.

Anyway, this is going way off-topic so this will be my last post in this
subthread. Feel free to reply off-list.

-- 
Sabri

please do not throw salami pizza away

Hurricane Wilma

[techlist]

It would be very helpful for operators to advise on any status they  
are seeing. Hopefully someone from the Nap Of The Americas can also  
provide some information.


Right now XO says they are experiencing some outages.  I have not see  
any outages from other providers but I am sure they exist.  Can  
anyone else advise?


The Southern Florida is currently without power.

David Diaz

RE: Hurricane Wilma

[Peering]

I have some customers down, probably due to power outages or Bell
issues, as I'm getting AIS on their ports.  Otherwise, we're operational
on generator power.  Hopefully, Wilma will move out soon so we can get
our techs back in and see what the neighborhood looks like.  I just hope
they're pretty quick to get commercial power back on.  Diesel is
expensive these days :-)

Diane Turley
Sr. Network Engineer
Xspedius Communications Co.
636-625-7178


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
techlist
Sent: Monday, October 24, 2005 9:32 AM
To: nanog@merit.edu
Subject: Hurricane Wilma



It would be very helpful for operators to advise on any status they  
are seeing. Hopefully someone from the Nap Of The Americas can also  
provide some information.

Right now XO says they are experiencing some outages.  I have not see  
any outages from other providers but I am sure they exist.  Can  
anyone else advise?

The Southern Florida is currently without power.

David Diaz

RE: Hurricane Wilma

[Chris Boyd]

I have a couple of customers hosted at Verio in Boca Raton.  We're
seeing routing issues inside Verio and no response from DNS, web and
SMTP servers.

--Chris

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> techlist
> Sent: Monday, October 24, 2005 9:32 AM
> To: nanog@merit.edu
> Subject: Hurricane Wilma
> 
> 
> 
> It would be very helpful for operators to advise on any status they  
> are seeing. Hopefully someone from the Nap Of The Americas can also  
> provide some information.
> 
> Right now XO says they are experiencing some outages.  I have not see  
> any outages from other providers but I am sure they exist.  Can  
> anyone else advise?
> 
> The Southern Florida is currently without power.
> 
> David Diaz
> 
> 

[nanog] Re: Hurricane Wilma

[Andrew White]

> Date: Mon, 24 Oct 2005 10:32:23 -0400
> From: techlist <[EMAIL PROTECTED]>
> To: nanog@merit.edu
> Subject: [nanog] Hurricane Wilma
>
> 
> It would be very helpful for operators to advise on any status they
> are seeing. Hopefully someone from the Nap Of The Americas can also
> provide some information.
[...]

Two data points:

We have connections from Honduras to NAP of the Americas; one via MAYA-1 
and one via ARCOS-1.  The MAYA-1 link is down hard, and the ARCOS service 
has been degraded at times (high packet loss / ping times) but has been 
working for the most part.

-Andrew

Re: [nanog] Re: Hurricane Wilma

[techlist]

Who is your transport into the NAP? Is it Bellsouth?

One interesting effect during the last hurricane was that Broward  
county customers (Ft Lauderdale is in that county) had no dial tone  
service but dsl was working.  Someone mentioned they lost the  
tandem.  The comment was made that voip phones were working and not  
the traditional lines which some found ironic.


I also see some people at the NAP down on XO but L3 and Broadwing etc  
are up down the street.


With some more information perhaps we will start to see where some  
common elements might have failed.


Anyone at the Bellsouth Grande CO with issues?

David Diaz


On Oct 24, 2005, at 11:13 AM, Andrew White wrote:















Date: Mon, 24 Oct 2005 10:32:23 -0400
From: techlist <[EMAIL PROTECTED]>
To: nanog@merit.edu
Subject: [nanog] Hurricane Wilma


It would be very helpful for operators to advise on any status they
are seeing. Hopefully someone from the Nap Of The Americas can also
provide some information.







[...]

Two data points:

We have connections from Honduras to NAP of the Americas; one via  
MAYA-1
and one via ARCOS-1.  The MAYA-1 link is down hard, and the ARCOS  
service
has been degraded at times (high packet loss / ping times) but has  
been

working for the most part.

-Andrew

Community Meeting Notes

[Matthew Petach]

(oops--sent this out last night, but forgot to change the
sender to the subscribed-to-nanog address first, 
gomennasai minnasan)

Matt


I took some notes at the NANOG community meeting
tonight, and thought I'd share them with the list members
in the spirit of transparency--apologies for the
typos that may still exist, I'm heading to the social now.  :)

Matt



2005.10.23 Steering Committee

Randy Bush, IIJ, Tokyo
current chair of the steering committee

Steering committee progress/status Randy
Program committee report (steve)
financial report (betty)
mailing list report (chris)

Other than vetted presentations, each speaks
as individual.

Microphone is open throughout.

How do we progress forward?

Steering committee report

what was asked for?
what has been done?
what should or will be done?
what does the community want?

REferences:
Dan Golding's "Why REfport NaNOG"
httpH;//ww.nanog.org/mtg-0501/pdf/golding.pdff
[EMAIL PROTECTED] mailing list archives
dissucions withing comjunity
charter is up

Mailing list
problem: contining problems witn NANOG mailing list
 administration
solutions: you asked for even moderation,
transparency, fairness, clue

So far: we now have a mailing list amdin group,
drawn from voluneers from the
community, tasked with moderating the list
Need: documented process, appeal, ... ie transparency
Philip Glass from Cisco, Bill Norton, Billo

Mailing list commitee: Rob Seastrom, Steven Gibbard,
Susan Harris, Chris Malayter,

Mailing ilist issues
SC process re ML comittee not in charter
terms
selection
prolicy and process review and approval
ML policy and process: document, get
c ommunity feedback and modify
ML appeals preoss: to SC

Program comittee
joe abley, 
bert russ, 
bill norton
pete templeton?

problem: percieved as being out of touch with
the general operator community, community powerless

solution: empower community to select content
so far: OPC transition from 100% merit select o sec 
  selecte 8 from exsiting PC, 8 from comminity 
 nominations with fixe gterms
so far: clearly identify PC members (nametags)
engage them: orange blobs on their badges!
To do: Steve will give PC reprort

PC selection by SC
Call for volunteers 12 re-ups and 18 new
PC/SC call to discuss new volunters
sub-SC formed of SC members who were
not also PC members
SC and sub-SC took input from public
and PC
sub-SC met and decided the eight to keep
Full SC met to decide which eight new
 volunteers to add
Too many good candidates!

2006 PC 
returnign
bill woodcock
chris morrow
dave oleary
hank kimler
joe abley
kevin epperson
steve feldman
ted seely

new 
danield goldin
jenniver rexford
jel gaeggli
josh snowohrn
pete templon

Charter
No proposals recived for this year
formalizing of ML for next year

General
Problem: no tranpsarency in the way NANOG is run
Solution: segmenting problem and externalizing 
  tranaparent processes
Steering comiitee is ultmately accountable to you
 --we own this one
so far: SC selected PC
so far: Merit/NANOG financial statements available 
 @NANOG
SC and PC have private butdirecty accesible mailing list
[EMAIL PROTECTED]
and [EMAIL PROTECTED] specifically for community 
 interaction with these two groups
SC minutes are publically archived

Still to Do
First time through this process (new PC,
SC working with Merit, etc) trial and error
Mailing list moderation still a challenge
need documentation and community discussion,
exploration of policy and proceedures
BLOG /Wiki/SlashNOG
Trial of new tech gear at NANOG

Adminstrative mailing lists
engineering and ops discussion only
[EMAIL PROTECTED]
open meta discussion
[EMAIL PROTECTED]
steering committee: [EMAIL PROTECTED]
program committee: [EMAIL PROTECTED]
ml admins [EMAIL PROTECTED]

Discussion?
Why do people come to NANOG?  What is it that
brings us together?

Meet face to face with people we interact with
electronically, 
find out new trends, new developments, find out
where the internet is going around the world.
Find out how to do her job more effectively.
Would like longer breaks--15 minutes is really
tough for syncing up with people.

USENIX facesavers--put faces to names would
probably be a nice thing to add on.

Good to get operational information *off the
record*, not just from

Bring back the lunches!!!  box lunches would be
easy, and would let people meet and greet.
Requires less time, allows for better interaction.

Good opportunity to meet with peers, people we
want to peer with, or people we need to smack for
bad peering.  :D

What about a calendar online for while we're at
NANOG, so people can schedule time to meet.

Susan Harris talks about lunch challenges--box
lunches would be better, less of a logistics 
challenge than getting sitdown space.

Steve Wilcox suggests that maybe trying to cut
down on the evening talks to allow more time to
talk to people.

Mike Hughes points out it's hard to have a program
that fits for 400 people as well as allows for
smaller gatherings.
He's also a wG chair for RIPE, and had troubl

Re: Community Meeting Notes

[Randy Bush]

thanks!

for the terminally bored, the foils i used are at



randy

Re: Level 3 RFO

[Daniel Roesen]

On Mon, Oct 24, 2005 at 01:25:23PM +0200, Florian Weimer wrote:
> >> Are there any configuration tweaks which can locally confine such an
> >> event?  Something like the hard prefix limit for BGP, perhaps.
> >
> > JunOS:
> > set protocols ospf prefix-export-limit 
> > set protocols isis level  prefix-export-limit 
> 
> Wouldn't an import limit be better?

We're talking link-state protocols here... they need to have the same
view everywhere. The only thing you can limit is what you inject into
the (IGP-)global view.

> If you've got a almost-fully-meshed MPLS core, export limits won't
> really work, will they?

I don't understand this question. What has MPLS to do with IGP route
filtering?!?


Regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0

RE: Level3 problems

[Gary Hale]

Not delusional ... just prefer it not be an "explicit" thread to all of
the community ... or ... consistent w/ your observation below (ref.
"lurking") ...

-gh

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Monday, October 24, 2005 9:57 AM
To: nanog@merit.edu
Subject: RE: Level3 problems


> Hmmm ... I suppose I would prefer this community not be made an
explicit
> source of information for a reporter. 

You're about 10 years too late. Reporters have been lurking
on the NANOG list for at least that long. Only the newbie
reporters post info requests to the lists. The pros send
private emails to list members or go to a NANOG meeting
and prowl the hallways.

Or did you somehow think that the Internet was a secret
network for the members of some private club?

--Michael Dillon

Re: [nanog] Re: Hurricane Wilma

[techlist]

XO NOC says they have outages in the S FL area. At the NAP there are definitely at least some customers down starting at just before 8am.  Last hurricane there were many people without dialtone in Broward.  I can tell you that since I experienced it.  I do not have any details on the cause directly from Bellsouth.  Maybe someone from XO's NOC can post here with any updates.DavidOn Oct 24, 2005, at 12:18 PM, Hannah, Patrick wrote:David,   I've got XO services in Broward and Dade, and fortunately, have not seen any outages. Have you heard anything in regard to XO services in South Florida? Services consist of both ISDN PRI and MMDS provisioned out of their DMS-500 in North Miami.   I can also report that some of these services utilize Grande as a Node on my SONET Ring and these do not appear to be affected either.   What details do you have in regard to the Bellsouth problems of the previous hurricane? I don't recall losing dialtone or the ability to dial Intra or Inter LATA or seeing this on the Bellsouth Interconnection site.   Hopefully this information helps.   Patrick   From: [EMAIL PROTECTED] on behalf of techlistSent: Mon 10/24/2005 11:21 AMTo: Andrew White; nanog@merit.eduSubject: Re: [nanog] Re: Hurricane Wilma Who is your transport into the NAP? Is it Bellsouth?One interesting effect during the last hurricane was that Broward county customers (Ft Lauderdale is in that county) had no dial tone service but dsl was working.  Someone mentioned they lost the tandem.  The comment was made that voip phones were working and not the traditional lines which some found ironic.I also see some people at the NAP down on XO but L3 and Broadwing etc are up down the street.With some more information perhaps we will start to see where some common elements might have failed.Anyone at the Bellsouth Grande CO with issues?David DiazOn Oct 24, 2005, at 11:13 AM, Andrew White wrote:> Date: Mon, 24 Oct 2005 10:32:23 -0400>> From: techlist <[EMAIL PROTECTED]>>> To: nanog@merit.edu>> Subject: [nanog] Hurricane Wilma>> It would be very helpful for operators to advise on any status they>> are seeing. Hopefully someone from the Nap Of The Americas can also>> provide some information.> [...]>> Two data points:>> We have connections from Honduras to NAP of the Americas; one via > MAYA-1> and one via ARCOS-1.  The MAYA-1 link is down hard, and the ARCOS > service> has been degraded at times (high packet loss / ping times) but has > been> working for the most part.>> -Andrew>  

Re: Level 3 RFO

[Florian Weimer]

* Daniel Roesen:

> On Mon, Oct 24, 2005 at 01:25:23PM +0200, Florian Weimer wrote:
>> >> Are there any configuration tweaks which can locally confine such an
>> >> event?  Something like the hard prefix limit for BGP, perhaps.
>> >
>> > JunOS:
>> > set protocols ospf prefix-export-limit 
>> > set protocols isis level  prefix-export-limit 
>> 
>> Wouldn't an import limit be better?
>
> We're talking link-state protocols here... they need to have the same
> view everywhere. The only thing you can limit is what you inject into
> the (IGP-)global view.

What a pity.  There isn't an ugly workaround, either?  There has to be
something that can be done, given the operational risk that is
involved.

Certainly, this adds a new dimension to the "distributed single point
of failure" concept. 8-(

>> If you've got a almost-fully-meshed MPLS core, export limits won't
>> really work, will they?
>
> I don't understand this question. What has MPLS to do with IGP route
> filtering?!?

It's the "almost fully-meshed" part.  In such a setup, a single router
which exceeds the limit can affect a large part of the the network,
even if other routers do not propagate the bogus data.

But as you say, if the limit you mentioned is just a local limit on
redistribution to the IGP for a single router, my point is moot--if
it's in the IGP, you lose because the limit does not apply to routes
which are received over the IGP.

Re: Recommendations for ISPs around the world

[Joel Jaeggli]

On Mon, 24 Oct 2005, Kim Onnel wrote:


For Africa, check out Equant and BT


For eastern europe I'm really at a loss, and Africa seems to lack regional
connectivity. All I can found is local stuff.


It's a whole continent. Some countries have more isp's, richer 
international connectivity and roboust, internal networks, others do not. 
If you need connectivty in a big city in nigeria or egypt you have 
different options than you do in say chad.


Differing regulatory regiemes, levels of political stability and vastly 
different levels of investment cause you options to be very different 
depending on where you need to go.



So, if anyone can give me a hand here, that would be greatly appreciated.

TIA,
Elmar.

--

"Begehe nur nicht den Fehler, Meinung durch Sachverstand zu
substituieren."
(PLemken, <[EMAIL PROTECTED]>)

--[ ELMI-RIPE
]---






--
--
Joel Jaeggli   Unix Consulting [EMAIL PROTECTED]
GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2

prepending 2 bytes of zeros....

[bmanning]

I am greatful to Geoff for his consistant ability to get me interested in
breaking things...   so, for the assembled mutlitude, what would the impact
on various peers be if I was to change my orign AS (ok, so i'll have to 
change the router code on my end to support this) from

4554

to

4554

Any ideas on how IOS (various flavors) will deal w/ this?  (yes, there is
some lab work to do first, but i don' think there is a comprehensive enough
lab to cover the full range of possibilities...)

--bill

Re: design of a real routing v. endpoint id seperation

[John Dupuy]

One way to do this is for two ISPs to band together
in order that each ISP can sell half of a joint
multihoming service. Each ISP would set aside a
subset of their IP address space to be used by many
such multihomed customers. Each ISP would announce
the subset from their neighbor's space which means
that there would be two new DFZ prefixes to cover
many multihomed customers.

Each multihomed customer would run BGP using a private
AS number selected from a joint numbering plan. This
facilitates failover if one circuit goes down but
doesn't consume unneccesary public resources per customer.

[...]

I've heard of this from others as well. It seems to be technically 
feasible, but I am curious about the social aspect: would ISPs actually do 
this? Would customer's find it acceptable? (given it still locks them to an 
ISP, now to two of them.)


In fact, this is technically feasible right now with IPv4. Does anyone know 
of a pair of ISPs doing this?


John  

Re: design of a real routing v. endpoint id seperation

[Valdis . Kletnieks]

On Mon, 24 Oct 2005 12:53:12 CDT, John Dupuy said:

> In fact, this is technically feasible right now with IPv4. Does anyone know 
> of a pair of ISPs doing this?

"technically feasible" and "business case reasonable" are two different things.

Under what conditions does this sort of cooperation with a competitor make 
sense?


pgpQnNfVuZEUb.pgp
Description: PGP signature

Re: design of a real routing v. endpoint id seperation

[Joe Maimon]

[EMAIL PROTECTED] wrote:


On Mon, 24 Oct 2005 12:53:12 CDT, John Dupuy said:


In fact, this is technically feasible right now with IPv4. Does anyone know 
of a pair of ISPs doing this?



"technically feasible" and "business case reasonable" are two different things.

Under what conditions does this sort of cooperation with a competitor make 
sense?


When your customer demands it and is willing to either pay for it or 
stop paying you for anything.

Re: design of a real routing v. endpoint id seperation

[Joe Abley]

On 24-Oct-2005, at 11:21, [EMAIL PROTECTED] wrote:


On Mon, 24 Oct 2005 12:53:12 CDT, John Dupuy said:

In fact, this is technically feasible right now with IPv4. Does  
anyone know

of a pair of ISPs doing this?


"technically feasible" and "business case reasonable" are two  
different things.


Under what conditions does this sort of cooperation with a  
competitor make sense?


As a customer, I would prefer to multi-home between ISPs who rarely  
talk to each other rather than those who are in collusion. From a  
technical perspective I want the operator-induced failures in each  
ISP to be as independent as possible; from the business perspective I  
want them both to fight for my money.



Joe

RE: Level3 problems

[Matt Ghali]

On Mon, 24 Oct 2005, Gary Hale wrote:

  Hmmm ... I suppose I would prefer this community not be made an 
  explicit source of information for a reporter. Implicitly, if 
  reporters must hang off this thread, they should be able to 
  discern impact from perspective given here. However, if questions 
  like the one(s) asked below became "standard" on this thread, then 
  soon the function of the group slants to something other than a 
  forum to aid (each other) in the proper "management" of the 
  affairs of Network Operators ... and may morph into something far 
  less useful.
  

Give me a break. This list becoming "less useful"?!
Alert the press! (or maybe not, according to you)

Traditionally, there has been a real knowledge gap between 
technology journalists and network operators. This has the negative 
effect of mainstream media presenting incorrect and/or skewed 
information regarding not only technical issues, but larger industry 
issues (including things like l3/cogent).

Without clued contacts, journalists are forced to glean their 
information from sources like vendor press releases and sales 
representatives.

Is that how you'd like the public's window into the industry 
colored? Do you really think that VendorSpeak really needs any more 
legitimizing?

matto

[EMAIL PROTECTED]<
  The only thing necessary for the triumph
  of evil is for good men to do nothing. - Edmund Burke

Re: prepending 2 bytes of zeros....

[Bjoern A. Zeeb]

On Mon, 24 Oct 2005 [EMAIL PROTECTED] wrote something
 about "prepending 2 bytes of zeros":

Hi,

> I am greatful to Geoff for his consistant ability to get me interested in
> breaking things...   so, for the assembled mutlitude, what would the impact
> on various peers be if I was to change my orign AS (ok, so i'll have to
> change the router code on my end to support this) from

I'll assume you are talking about BGP.


>   4554
>
>   to
>
>   4554

actually these are 4 bytes of leading zeros because you are in decimal
but it's ok;)

How would you change the code?
"My Autonomous System" is an 2 octet unsigned integer and leading
zeros are of no value. So the number above still is 4554.

In case you'd hardcode that as 0x 0x11ca you'd overflow and depending
on your coding you my either overwrite "Hold Time" or generate some kind of
invalid packet with bad BGP Identifier and bad overall length (considering
"Opt Parm Length") or overwrite some of your local memory...


> Any ideas on how IOS (various flavors) will deal w/ this?  (yes, there is
> some lab work to do first, but i don' think there is a comprehensive enough
> lab to cover the full range of possibilities...)

Depending on what checks the code runs you should run into an error
one way or the other and not get back a NOTIFICATION message - if you
hard code those 32bit given above then you might get sth like subcode
2, 4 or 6. It should be treated like any other (specially crafted)
invalid packet.


-- 
Greetings
Bjoern A. Zeeb  bzeeb at Zabbadoz dot NeT

Re: prepending 2 bytes of zeros....

[Geoff Huston]

At 03:46 AM 25/10/2005, [EMAIL PROTECTED] wrote:



I am greatful to Geoff for his consistant ability to get me interested in
breaking things...   so, for the assembled mutlitude, what would the impact
on various peers be if I was to change my orign AS (ok, so i'll have to
change the router code on my end to support this) from

4554

to

4554

Any ideas on how IOS (various flavors) will deal w/ this?  (yes, there is
some lab work to do first, but i don' think there is a comprehensive enough
lab to cover the full range of possibilities...)



So lets say you are running a BGP version that supports 4-Byte AS code, and 
you local AS is 4554


When you open a session with your BGP peer (using in this case 4554 in the 
2-byte My AS field of the OPEN packet) you will send a BGP capacility 
advertisement to your peer, indicating your willingness to exchange 4-Byte 
AS numbers with your peer.


At this stage IOS (various flavours) do not (to my limited knowledge) 
support this capability, so you will not get a positive response to your 
capability announcement, so you are now on a NEW / OLD transition boundary. 
Your BGP will now operate in this NEW / OLD transition mode. The behaviour 
now depends on whether you are an isolated 0:4554 island, or whether there 
are any 4-Byte AS's that directly peer with your AS.


In the former case you will strip off the leading zero 2-Byte fields from 
your BGP Updates when you pass them to your BGP peer


The the latter case the action will vary, depending on whether the 4-Byte 
AS's in the path are all zero-strippable or not. In the latter case the 
UPDATES will cause a NEW_AS_PATH attribute to be added to the UPDATES you 
generate. in the former case its zero stripping.


So does this answer your question?

  Geoff

WI.RR.com

[Jeffrey Sharpe]

If there is a Road Runner mail server admin on the list,
could you please contact me off-list.

 



Jeffrey Sharpe

CyberLynk Helpdesk and Support

414.858.9335 or 800.942.8022

Cell: 262.488.0242

[EMAIL PROTECTED]



 

 

Re: What is multihoming was (design of a real routing v. endpoint id seperation)

[Stephen Sprunk]

Thus spake <[EMAIL PROTECTED]>

> the market wouldn't
> feel the need to have to dual home.



the internet model is to expect and route around failure.


Seems to me that there is some confusion over the meaning
of "multihoming". We seem to assume that it means BGP multihoming
wherein a network is connected to multiple ASes and uses BGP
to manage traffic flows.


AFAICT, that is the accepted definition in this forum.  Anything less is 
best called by a different, more precise term to avoid confusion.



Other people use this term in very different ways. To some people
it means using having multiple IP addresses bound to a single
network interface. To others it means multiple websites on one
server.


That is virtual hosting in a NANOG context.  Some undereducated MCSEs might 
call it multihoming, but let's not endorse that here.



A single tier-2 ISP who uses BGP multihoming with several
tier 1 ISPs can provide "multihoming" to it's customers
without BGP. For instance, if this tier-2 has two PoPs
in a city and peering links exist at both PoPs and they
sell a resilient access service where the customer has
two links, one to each PoP, then it is possible to route
around many failures. This is probably sufficient for most
people and if the tier-2 provider takes this service seriously
they can engineer things to make total network collapse exteremely
unlikely.


I bet customers who bought two links to Cogent no longer believe they're 
"multihomed"; policy failures are disturbingly frequent in Tier 2s, 
particularly those wanting to join the Tier 1 club.  Total network failures 
are rarer, but even folks like UUNET, WorldCom, AT&T, MCI, etc. have them 
from time to time.  With restoral times measured in days on both types of 
occasions, you can't discount them as "extremely unlikely" if your business 
can't function without a network.  Ask the folks at Starbucks how many 
millions of dollars of coffee they gave away when their cash registers 
didn't work for a couple days... and how many customers (i.e. future 
revenue) they would have lost if they hadn't.


Two links to the same provider is merely "redundancy" or "link/POP 
diversity", not multihoming.  Don't let your marketing department override 
your common sense or engineering clue.


S

Stephen Sprunk"Stupid people surround themselves with smart
CCIE #3723   people.  Smart people surround themselves with
K5SSS smart people who disagree with them."  --Aaron Sorkin

Re: What is multihoming was (design of a real routing v. endpoint id seperation)

[Crist Clark]

Stephen Sprunk wrote:
[snip]


Other people use this term in very different ways. To some people
it means using having multiple IP addresses bound to a single
network interface. To others it means multiple websites on one
server.



That is virtual hosting in a NANOG context.  Some undereducated MCSEs 
might call it multihoming, but let's not endorse that here.


Unfortunately, this is a common and "standards blessed" way to refer to
any host with multiple interfaces/addresses (real or virtual). For example,
from the "Terminology" section, 1.1.3, of RFC1122, "Requirements for
Internet Hosts -- Communication Layers," says,

 Multihomed
  A host is said to be multihomed if it has multiple IP
  addresses.  For a discussion of multihoming, see Section
  3.3.4 below.

--
Crist J. Clark   [EMAIL PROTECTED]
Globalstar Communications(408) 933-4387

The information contained in this e-mail message is confidential,
intended only for the use of the individual or entity named above.
If the reader of this e-mail is not the intended recipient, or the
employee or agent responsible to deliver it to the intended recipient,
you are hereby notified that any review, dissemination, distribution or
copying of this communication is strictly prohibited.  If you have
received this e-mail in error, please contact [EMAIL PROTECTED]

Re: What is multihoming was (design of a real routing v. endpoint id seperation)

[Valdis . Kletnieks]

On Mon, 24 Oct 2005 13:31:17 PDT, Crist Clark said:
> 
> Stephen Sprunk wrote:
> [snip]
> 
> >> Other people use this term in very different ways. To some people
> >> it means using having multiple IP addresses bound to a single
> >> network interface. To others it means multiple websites on one
> >> server.
> > 
> > 
> > That is virtual hosting in a NANOG context.  Some undereducated MCSEs 
> > might call it multihoming, but let's not endorse that here.
> 
> Unfortunately, this is a common and "standards blessed" way to refer to
> any host with multiple interfaces/addresses (real or virtual).

I think Stephen meant "Some undereducated McSE (you want fries with that?)
call "multiple websites on one server" "multihoming".


pgpkX5TH1Cunu.pgp
Description: PGP signature

RE: Really odd pings going out - Found It's SKYPE!

[Nicole]

 Hi
 Thanks to everyone who sent helpfull advice for tracking this down.
 I wanted to follow up and say that I tried every test imaginable and nothing
was found.

 finnaly I got a period were I could do without skype and found that when
skype was off.. No more pings were going out at random times to networks all
over.

 So.. I have no idea why skpe is doing that. I even upgraded it (as it
requested due to a newer version being out when I relogged back in)
 And once again the pings go out. 

 Seems Damn odd for Skype to be doing that.
 

  Nicole



On 19-Oct-05 the GW commando coersion squad reported Nicole said :
> 
> 
> 
>  Hello All.
>   I have seen people writing in now and again with things like this and I
> never
> thought I would be one of them. But here goes.
> 
>  After doing a netgear firewall upgrade which suplpied some extra
> information,
> I started noticing these odd pings to all over the place from a computer I
> have.
> I don't notce any attempted return traffic from the same Ip's. So I am
> at a loss as to what this could be or why. Any thoughts would be appreciated.
>  
> 
> - Destination:204.152.43.107,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo
> Request],LAN
> - Destination:130.244.175.141,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo
> Request],LAN
> - Destination:202.139.21.27,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo
> Request],LAN
> - Destination:202.232.175.9,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo
> Request],LAN
> - Destination:204.152.43.107,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo
> Request],LAN
> - Destination:130.244.175.141,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo
> Request],LAN
> - Destination:202.139.21.27,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo
> Request],LAN
> - Destination:202.232.175.9,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo
> Request],LAN
> - Destination:204.152.43.107,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo
> Request],LAN
> - Destination:130.244.175.141,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo
> Request],LAN
> - Destination:202.139.21.27,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo
> Request],LAN
> - Destination:202.232.175.9,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo
> Request],LAN
> - Destination:204.152.43.107,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo
> Request],LAN
> - Destination:130.244.175.141,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo
> Request],LAN
> - Destination:202.139.21.27,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo
> Request],LAN
> - Destination:202.232.175.9,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:28 - ICMP packet - Source:192.168.1.3,[Echo
> Request],LAN
> - Destination:151.164.243.2,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:29 - ICMP packet - Source:192.168.1.3,[Echo
> Request],LAN
> - Destination:151.164.243.2,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:30 - ICMP packet - Source:192.168.1.3,[Echo
> Request],LAN
> - Destination:151.164.243.2,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 16:11:02 - ICMP packet - Source:192.168.1.3,[Echo
> Request],LAN
> - Destination:204.152.167.33,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 16:11:02 - ICMP packet - Source:192.168.1.3,[Echo
> Request],LAN
> - Destination:130.244.203.3,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 16:11:02 - ICMP packet - Source:192.168.1.3,[Echo
> Request],LAN
> - Destination:202.139.215.213,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 16:11:02 - ICMP packet - Source:192.168.1.3,[Echo
> Request],LAN
> - Destination:202.232.11.117,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 16:11:02 - ICMP packet - So

Re: What is multihoming was (design of a real routing v. endpoint id seperation)

[John Reilly]

On Mon, 2005-10-24 at 10:01 +0100, [EMAIL PROTECTED] wrote:
> Other people use this term in very different ways. To some people
> it means using having multiple IP addresses bound to a single
> network interface. To others it means multiple websites on one
> server.

Do you not mean a single host with multiple interfaces?  I didn't think
anyone with multiple IPs on a single interface would consider it to be
multihomed.

Re: What is multihoming was (design of a real routing v. endpoint id seperation)

[John Reilly]

On Mon, 2005-10-24 at 02:24 -0700, Owen DeLong wrote:
> As I understand it, the term multihoming in a network operations
> context is defined as:
> 
> (A multihomed network is)
> A network which is connected via multiple distinct
> paths so as to eliminate or reduce the likelihood that a single
> failure will significantly reduce reachability.

Given that definition of multhoming.

> 3.Most multihoming today is done using BGP, but, many other
>   solutions exist with various tradeoffs.  In V6, there is
>   currently only one known (BGP) and one proposed, but,
>   unimplemented (Shim6) solution under active consideration
>   by IETF. (this may be untrue, but, it seems to be the
>   common perception even if not reality).


... shim6 doesn't fit into the definition does it?  Its seems to be a
question of multihomed networks Vs. multihomed hosts (although the
effect may be the same at the end of the day).

Re: Customer view vs. operator view was:( h-root-servers.net)

[Peter Dambier]

Thank you Michael,

for throwing light into this.

Yes, I see, Sabri and me are on two different rails, one leading north,
the other one leading east. I hope Sabri still has got all his hairs.
I am counting mine now.

Kind regards and thank you again,

Peter Dambier


[EMAIL PROTECTED] wrote:

I know of one host here in germany who can see h.root-servers.net.
That host is living in a KPN data centre directly connected to 


Amterdam


IX.


Your own traceroute clearly shows that your host is not directly
connected to the AMS-IX. Nor does the KPN datacenter it resides in. The
AMS-IX has 4 datacenters where members can place equipment which can be
directly connected to the AMS-IX:

- GlobalSwitch;
- Sara;
- Nikhef;
- Telecity2, Kuiperbergerweg;

Every statement otherwise is bogus, nonsense, crap or whatever term you
prefer to use for this.



This is a good example of a useless argument caused when one
person is speaking from a customer viewpoint and one customer
is speaking from an operator viewpoint.

Assume that there is an ISP X with a data center in Germany
and a colocated rack at Nikhef. They peer directly with many
other providers through AMS-IX from their Nikhef location.
Customer Q comes along and places a server in their data centre 
in Germany because he needs to serve his users both in Germany and

in his chain of hotels throughout Holland. His network people assure
him that the server is connected directly to AMS-IX because that
is what their traceroutes say.

Of course, we know better. We know that the server is connected
directly to ISP X and indirectly to AMS-IX because we are
used to being particular about which operator owns each
hop. But the customer Q doesn't see the hops in network X. 
To him, they are invisible because they are his HOME network.

Customers don't see themselves as network operators and therefore
they often think of their ISP's network as their own.

So who is right? Peter? Sabri? Both?
My opionion is that neither of them is right because they
both failed to understand what the real problem is and
they both failed to take the correct steps to solve the
problem. As it happens, this was a very, very basic
network issue which does not need to be discussed on
NANOG at all.

--Michael Dillon




--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason

ICANN and Verisign settle over SiteFinder

[Chris Woodfield]

Said the flowerpot: "Oh no, not again..."

http://www.businessweek.com/ap/financialnews/D8DEL2TO7.htm? 
campaign_id=apn_tech_down&chan=tc


-C

open jabber server and conference room for nanog-arin meeting

[Paul Vixie]

in an unusual fit of effacacy, i brought up an open jabber server today
and created a persistent conference room.  i'm not a fan of the monolithic
public jabber.org server.

if you have a jabber account somewhere, you can join the conference room:

   [EMAIL PROTECTED]

if you don't have a jabber account somewhere, you can register one at:

   jabber.tisf.net

if you don't have a jabber client, my recommendations are:

   mac/os/x   adium-x or psi
   windowspandion or psi
   bsd or linux   psi or tkabber

i've been told that srh might monitor this jabber room during tuesday's
meeting, in case questions come in from folks listening to the broadcast.

Re: Scalability issues in the Internet routing system

[Tony Li]

On Oct 23, 2005, at 11:33 PM, Alexei Roudnev wrote:



One question - which percent of routing table  of any particular  
router is

REALLY used, say, during 1 week?

I have a strong impression, that answer wil not be more than 20%  
even in

biggerst backbones, and
will be (more likely) below 1% in the rest of the world. Which  
makes a hige

space for optimization.



As of the last time that I looked at it (admittedly quite awhile  
ago), something like 80% of the forwarding table had at least one hit  
per minute.  This may well have changed given the number of traffic  
engineering prefixes that are circulating.


Tony

Re: Scalability issues in the Internet routing system

[Blaine Christian]

As of the last time that I looked at it (admittedly quite awhile  
ago), something like 80% of the forwarding table had at least one  
hit per minute.  This may well have changed given the number of  
traffic engineering prefixes that are circulating.


Tony



Yea, but that's just me pinging everything and google and yahoo  
fighting over who has the most complete list of x rated sites.

VoIP Security Threat Taxonomy: Request for Comments

[David Endler]

The Voice over IP Security Alliance (VOIPSA) is pleased to announce the 
first draft release of the VoIP Security Threat Taxonomy.  The draft is 
available at http://www.voipsa.org/Activities/taxonomy.php and your comments 
are greatly appreciated.  In fact, we've opened up the online wiki 
specifically for collecting your feedback.  Many thanks to the project 
leader Jonathan Zar and all of the volunteers who dedicated their time and 
energy to this first release.


-dave

David Endler
VOIPSA Chairman




ABOUT VOIPSA:

The Voice over IP Security Alliance (VOIPSA) aims to fill the void of VoIP 
security related resources through a unique collaboration of VoIP and 
Information Security vendors, providers, thought leaders, and users. 
VOIPSA's mission is to drive adoption of VoIP by promoting the current state 
of VoIP security research, VoIP security education and awareness, and free 
VoIP testing methodologies and tools.  Get involved at http://www.voipsa.org 

Re: open jabber server and conference room for nanog-arin meeting

[Susan Harris]

Many thanks for doing this Paul.  As far as me monitoring, I've never had 
any luck getting a jabber client going so help would be welcome.  And, if 
anyone in the audience sees a question come in, don't hesitate to go up to 
the mike and ask it.


On Tue, 25 Oct 2005, Paul Vixie wrote:



in an unusual fit of effacacy, i brought up an open jabber server today
and created a persistent conference room.  i'm not a fan of the monolithic
public jabber.org server.

if you have a jabber account somewhere, you can join the conference room:

  [EMAIL PROTECTED]

if you don't have a jabber account somewhere, you can register one at:

  jabber.tisf.net

if you don't have a jabber client, my recommendations are:

  mac/os/xadium-x or psi
  windows pandion or psi
  bsd or linuxpsi or tkabber

i've been told that srh might monitor this jabber room during tuesday's
meeting, in case questions come in from folks listening to the broadcast.

!DSPAM:435d7aa327733327503325!

Re: What is multihoming was (design of a real routing v. endpoint id seperation)

[Owen DeLong]

I believe RFC1122 was written in the days when there was a one-to-one
correlation
between IP addresses and interfaces, and, you couldn't have one machine with
multiple addresses on the same network.  Obviously, also, we are talking
about
network multihoming, not host multihoming in a NANOG context.  It is hard
to perceive a situation where Host Multihoming would require coordination.

Owen


--On October 24, 2005 1:31:17 PM -0700 Crist Clark
<[EMAIL PROTECTED]> wrote:

> 
> Stephen Sprunk wrote:
> [snip]
> 
>>> Other people use this term in very different ways. To some people
>>> it means using having multiple IP addresses bound to a single
>>> network interface. To others it means multiple websites on one
>>> server.
>> 
>> 
>> That is virtual hosting in a NANOG context.  Some undereducated MCSEs 
>> might call it multihoming, but let's not endorse that here.
> 
> Unfortunately, this is a common and "standards blessed" way to refer to
> any host with multiple interfaces/addresses (real or virtual). For
> example,
> from the "Terminology" section, 1.1.3, of RFC1122, "Requirements for
> Internet Hosts -- Communication Layers," says,
> 
>   Multihomed
>A host is said to be multihomed if it has multiple IP
>addresses.  For a discussion of multihoming, see Section
>3.3.4 below.
> 
> -- 
> Crist J. Clark   [EMAIL PROTECTED]
> Globalstar Communications(408) 933-4387
> 
> The information contained in this e-mail message is confidential,
> intended only for the use of the individual or entity named above.
> If the reader of this e-mail is not the intended recipient, or the
> employee or agent responsible to deliver it to the intended recipient,
> you are hereby notified that any review, dissemination, distribution or
> copying of this communication is strictly prohibited.  If you have
> received this e-mail in error, please contact [EMAIL PROTECTED]



-- 
If it wasn't crypto-signed, it probably didn't come from me.


pgpLC3TxiLj7v.pgp
Description: PGP signature

Re: What is multihoming was (design of a real routing v. endpoint id seperation)

[Owen DeLong]

> ... shim6 doesn't fit into the definition does it?  Its seems to be a
> question of multihomed networks Vs. multihomed hosts (although the
> effect may be the same at the end of the day).
> 
> 
Yes... The network is still multihomed, but, instead of using routing to
handle the source/dest addr. selection, it is managed at each end host
independent of the routers.  The routers function sort of like the
network is single homed.  It's very convoluted.


Owen



-- 
If it wasn't crypto-signed, it probably didn't come from me.


pgpFoAy33vdT9.pgp
Description: PGP signature

Re: open jabber server and conference room for nanog-arin meeting

[Paul Vixie]

jabber update.  folks have reported some unreachability, but being network
admins, did not say "ping worked" (or not) and didn't send a traceroute.  if
they'd done either, i'd've asked "what server were you logged into", since
the connection that's failing is server-to-server (from the server where you
are logged in, to the conference server).

if you want to get into this conference room and your jabber server is timing
out trying to reach my jabber server, please send me ping and traceroute
results (as well as "telnet jabber.tisf.net 5222" results) while standing on
your server.

otoh, you can probably work around the problem by registering a new account
at jabber.tisf.net (it's open to registration from anybody) and then joining
the [EMAIL PROTECTED] mailing list from there (which is
a connection from localhost to localhost from my server's point of view.)

sorry for the churn.  and yes, srh, if someone asks a Q on jabber and you're
not logged in, i'll spew it to the microphone (or somebody else will).
-- 
Paul Vixie

Re: ICANN and Verisign settle over SiteFinder

[Florian Weimer]

* Chris Woodfield:

> Said the flowerpot: "Oh no, not again..."
>
> http://www.businessweek.com/ap/financialnews/D8DEL2TO7.htm? 
> campaign_id=apn_tech_down&chan=tc

I don't understand what VeriSign receives in return for their kowtow
(under the agreement, they basically waive any right to criticize
ICANN's role).

Two possible explanations:

  * ICANN signalled a positive outcome of a future Sitefinder review
under the new process.

  * ICANN promised to grant VeriSign the DNSSEC root and .ARPA
maintenance without tender (the "Root Server Management Transition
Agreement" goes into that direction; actually, the .ARPA stuff is
the interesting one).

  * VeriSign has recognized that they couldn't win in court, and
suddenly want to play nice.