[6bone] pTLA request NDSOFTWARE - review closes 23 October 2002
John Fraizer
tvo@EnterZone.Net
Sun, 20 Oct 2002 04:42:20 -0400 (EDT)
On 20 Oct 2002, Nicolas DEFFAYET wrote:
> On Sat, 2002-10-19 at 23:58, John Fraizer wrote:
>
> John,
>
> > If your routers are full, BUILD ANOTHER ROUTER to add to your v6 core.
> > You don't drop one peer to bring on another. Your new "policy" sucks,
> > plain and simple and for this reason, I can NOT support your request for a
> > pTLA.
>
> We don't have budget for build anoter 6bone router.
> We want start a pre-production network, all new routers will be for
> pre-production network.
>
OK. What keeps you from putting 6bone peers and your
"pre-production" peers on the same router? Personal choice. There is no
technical barrior to doing so. You are self imposing the barrior based on
policy.
> Yes, our new policy sucks but i don't have better solution.
>
> I know that my email to this peers wasn't diplomatic.
>
> You provide to an user a BGP4+ peering, after you can't keep the tunnel
> for technical reasons (routers full), do you will like that this user
> troll about you on public mailing-list ?
First of all, trolling is the act of LOOKING for something. I don't think
that anyone has been LOOKING for anything from you besides answers to
questions to which you have been highly evasive. Second of all, if you
can't take the heat of having a user talk about you in a public forum, you
had might as well drop out and cut your losses. If you ever run a
_real_ network, it's going to happen. I don't care how perfect your
network performs. Some customer somewhere is going to experience a
problem, be it theirs, yours or something 15 as-hops away from you and
they're going to blame YOU for it in a very loud way on a public
forum. Childish replies such as those you've presented the list with
thusfar only serve to prove their point and do NOTHING to help convince
myself or others that you are a good candidate for a peer, let alone one
with a pTLA.
>
> One of users who have received my email, contact me (no on public
> mailing-list), for get many informations about this problem.
> He reply to me "I understand your problem, good luck for your IPv6
> network.". If we have free bgp session on our routers later, i will
> recontact him.
> It's a normal reply. Christian, don't contact me but troll on public
> mailing-listing about me, it's not a normal reply, it's a revenge.
My, you're full of yourself, aren't you? Do you for some reason think
that the person in question can't get a peering session with any number of
other 6bone participants? From what I saw, he was venting about the WAY
you did it rather than the fact that you did it.
>
> > Just an FYI: You violated OUR peering policy when you dropped your peering
> > session to change your ASN. If you investigate a bit, you'll notice that
> > it is possible to have Zebra speak as multiple ASNs at once. You simply
> > changed your ASN and "poof" the session dropped. No biggie. Just thought
> > I would bring that to your attention.
>
> With Zebra 0.93b multi-as on the same router don't work fine.
>
Strange. I haven't seen anyone make a bug report to the Zebra list
regarding this problem. I have also personally used this feature in our
testbed without issue. If you're having issues with the _FREE_ routing
software that you're using, don't you suppose that you have an obligation
to at least post to the list regarding the issue so that those who work on
the code can actually try to diagnose and fix the problem?
> I have send to you a email, i wait 24 hours, no reply, reply of other, i
> switch the ASN of the router.
>
The only email I received from you cam AFTER you had changed your ASN on
your bgp config. I am fairly certain that there was no issue with our
mailserver(s) as my standard 200-300 emails per day have been constant for
several years now.
Now. let me pose some questions to you. Your open, honest answers to
these questions will determine my vote (and perhaps many others) on your
pTLA application:
(1) Who are the following and what are their qualifications to be
technical contacts? The last thing I want to hear on the other end of the
phone line when I contact someones technical contacts is "I'm sorry.
He's at school. I'll tell him you called." Do these people all have
enable on your routers? Do they understand v6 routing? Would they know
what I was talking about if I told them that you were leaking leaking
routes or that your peering session was flapping?
person: Chris BURTON
address: NDSoftware
address: 57 rue du president Wilson
address: 92300 Levallois-Perret
address: France
phone: +33 671887502
e-mail: chris.burton@ndsoftware.net
nic-hdl: CB2-6BONE
notify: notify@ndsoftwarenet.com
mnt-by: MNT-NDSOFTWARE
changed: chris.burton@ndsoftware.net 20021015
source: 6BONE
person: Bruno NASH
address: NDSoftware
address: 57 rue du president Wilson
address: 92300 Levallois-Perret
address: France
phone: +33 671887502
e-mail: bruno.nash@ndsoftware.net
nic-hdl: BN3-6BONE
notify: notify@ndsoftwarenet.com
mnt-by: MNT-NDSOFTWARE
changed: bruno.nash@ndsoftware.net 20021015
source: 6BONE
person: Myriam MOREL
address: NDSoftware
address: 57 rue du president Wilson
address: 92300 Levallois-Perret
address: France
phone: +33 671887502
e-mail: myriam.morel@ndsoftware.net
nic-hdl: MM14-6BONE
notify: notify@ndsoftwarenet.com
mnt-by: MNT-NDSOFTWARE
changed: myriam.morel@ndsoftware.net 20021015
source: 6BONE
person: Mike CHENEY
address: NDSoftware
address: 57 rue du president Wilson
address: 92300 Levallois-Perret
address: France
phone: +33 671887502
e-mail: mike.cheney@ndsoftware.net
nic-hdl: MC7-6BONE
notify: notify@ndsoftwarenet.com
mnt-by: MNT-NDSOFTWARE
changed: mike.cheney@ndsoftware.net 20021015
source: 6BONE
(2) Do you have a network plan? IE; How are your current /32's
dispersed?
(3) Do _you_ have a network or are you simply colocated someplace on
someone elses network?
If you're colocated, do you #1 have 24hr _physical_ access to the
equipment? Can you be onsite within a reasonable amount of time in the
event that physical access to equipment is required to remedy a
problem? If not, do you have a "remote hands" contract in place?
This is a serious pet peeve with me. There are far too many
"posers" claiming to have networks and datacenters that in truth have a
19" x 19" space in someone elses datacenter.
Looking a bit at v4 address registries, I see the following:
parcr1.fr.ndsoftwarenet.net (213.91.4.3)
inetnum: 213.91.4.0 - 213.91.4.127
netname: FR-TEASER
descr: FIRSTREAM.NET hosted servers
country: FR
admin-c: HRA81-RIPE
tech-c: HRA81-RIPE
rev-srv: ns0.teaser.net
rev-srv: ns1.teaser.net
status: ASSIGNED PA
remarks: Please report all abuse related issues to
remarks: abuse@firstream.net
notify: hostmaster@teaser.net
mnt-by: FT-NOC
changed: at@teaser.net 20011220
source: RIPE
parcr2.fr.ndsoftwarenet.net (62.4.18.114)
inetnum: 62.4.16.0 - 62.4.20.255
netname: NERIM-1
descr: Nerim is an Internet Service Provider
descr: based in France
country: FR
admin-c: RB7192-RIPE
tech-c: RB7192-RIPE
rev-srv: maridia.nerim.net
rev-srv: metroid.nerim.net
rev-srv: noemie.nerim.net
status: ASSIGNED PA
notify: ripe@isdnet.net
mnt-by: ISDNET-NOC
changed: dly@isdnet.net 19991201
changed: dly@isdnet.net 20001012
changed: kbrebion@isdnet.net 20001018
source: RIPE
(4) If you don't have your own network, how do you propose to provide
"production quality" 6bone backbone services?
I submit that without your own portable v4 address space for an endpoint
of tunnels, you're at the mercy of your upstreams. If they require you to
renumber, every one of your peers will have to reconfigure their tunnels.
(5) I find this strange. Can you explain it?
$ traceroute6 parcr1.fr.ndsoftwarenet.net
traceroute to parcr1.fr.ndsoftwarenet.net (3ffe:81f1:2:1::1) from 3ffe:4010:ff09::1, 30 hops max, 16 byte packets
1 enterzone-ndsoftware-gw.paris.ipv6.enterzone.net (3ffe:4010:ff09::2) 421.357 ms 438.313 ms 419.447 ms
2 bb1v6-sgr-tu0.muc.ipv6.eurocyber.net (2001:768:e:12::2) 492.543 ms 555.586 ms 530.186 ms
3 bb1v6-rkp-tu7.muc.ipv6.eurocyber.net (2001:768:e:14::1) 531.863 ms 603.233 ms 606.157 ms
4 feth0-1-parcr1.fr.ndsoftwarenet.net (3ffe:81f1:0:1::1) 1030.55 ms 1141.35 ms 1132.64 ms
5 bb1v6-rkp-tu7.muc.ipv6.eurocyber.net (2001:768:e:14::1) 724.858 ms 772.424 ms 725.722 ms
6 feth0-1-parcr1.fr.ndsoftwarenet.net (3ffe:81f1:0:1::1) 1212.88 ms 1316.88 ms 1484.25 ms
7 bb1v6-rkp-tu7.muc.ipv6.eurocyber.net (2001:768:e:14::1) 881.822 ms 924.786 ms 892.842 ms
Nice routing loop there. Have you considered: (1) Not having a v6 default on your border
router. (2) Having a connection between your two border routers and running an IGP between them?
(6) It can't be a good sign for a "production quality" network when your
route-server can't maintain a BGP peering session with your own routers:
route-server.ndsoftwarenet.net> sh ipv6 bgp sum
BGP router identifier 10.0.1.2, local AS number 25358
246 BGP AS-PATH entries
9 BGP community entries
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
3ffe:81f1:0:1::1
4 25358 0 2139 0 0 0 00:04:12 OpenSent
3ffe:81f1:0:2::1
4 25358 13207 5127 0 0 0 3d08h30m 310
Total number of neighbors 2
(7) "a. Fully maintained, up to date, 6Bone Registry entries for their
ipv6-site inet6num, mntner, and person objects, including each
tunnel that the Applicant has."
You've got parcr3.fr.ndsoftwarenet.net listed in your ipv6-site object but:
$ traceroute parcr3.fr.ndsoftwarenet.net
traceroute: unknown host parcr3.fr.ndsoftwarenet.net
$ traceroute6 parcr3.fr.ndsoftwarenet.net
traceroute: unknown host parcr3.fr.ndsoftwarenet.net
(8) With regards to #7 above, I suggest that with your recent policy
change regarding BGP peers, you remove the following line from your
ipb6-site object:
remarks: NDSoftware have an open peering policy.
(9) What is your "potential user community" IE; What gap are you going to
be filling in the service delivery arena that is not already served by
other pTLAs?
(10) What purpose will having your OWN pTLA serve that your current 3
/32's don't already serve? Keep in mind that _wanting_ your own pTLA !=
_NEEDING_ your own pTLA and _NEEDING_ to announce a pTLA into the DFZ
because it's a requirement for you to have your own ASN is _not_
sufficient justification for you to be issued a pTLA.
(11) "d. A fully maintained, and reliable, IPv6-accessible system
providing, at a mimimum, one or more web pages, describing the
Applicant's IPv6 services. This server must be IPv6 pingable."
Looking at http://noc.ndsoftwarenet.com, information about what
NDSOFTWARE actually *does* is strangely absent. Your peering-policy link
returns a 404 error. Your route-filtering link returns a 404 error. Your
usenet-policy link returns a 404 error. Register, Login and Help all
point to your bgp-communities page, as do your "go" button and the
advanced-search link. Home, Products & Services, Support, Download, Buy
and Contact links at the top page simply link the whatever page you're
currently viewing. There is no information about what your
"company?" actually does or offers to do even.
(12) "b. Fully maintained, and reliable, BGP4+ peering and connectivity
between the Applicant's boundary router and the appropriate
connection point into the 6Bone. This router must be IPv6
pingable. This criteria is judged by members of the 6Bone
Operations Group at the time of the Applicant's pTLA request.
We have currently 101 BGP4+ sessions."
Looking at parcr1.fr.ndsoftwarenet.net, I count 87 neighbors, 15 of which
are down, 3 of which have never established an adjacency, two of the 87
peering sessions being yourself. (84 ?real? sessions on this router.)
Looking at parcr2.fr.ndsoftwarenet.net, I count 11 neighbors, 4 of which
are down with two of the 11 peering sessions being yourself. (9
?real? peering sessions.)
I don't know about in France but, in the US, 84 + 9 = 93 peering sessions,
not 101 peering sessions.
Can you perhaps explain your math to us?
(13) Of those 84 peering sessions, have you verified that they have
appropriate entries in their ipv6-site objects for the tunnel/connection
or that they have ipv6-site objects AT-ALL? Before you answer this, take
a look at this:
IPv6 in IPv4 parcr1.fr.ndsoftwarenet.net -> 213.121.24.91 UK6X BGP4+
*** UK6X: Destination site does not appear in registry - check spelling
against registry and remove any extra text
IPv6 in IPv4 parcr1.fr.ndsoftwarenet.net -> ge3-1.er1a.fra2.de.mfnx.net
DE-TRMD-SBI-1 BGP4+
*** DE-TRMD-SBI-1: Destination site does not appear in registry - check
spelling against registry and remove any extra text
IPv6 in IPv4 parcr1.fr.ndsoftwarenet.net ->
modemcable049.63-201-24.mtl.mc.videotron.ca SYNCROS BGP4+
*** SYNCROS: Destination site does not appear in registry - check spelling
against registry and remove any extra text
IPv6 in IPv4 parcr1.fr.ndsoftwarenet.net -> worldakt.com WORLDAKT BGP4+
*** WORLDAKT: Destination site does not appear in registry - check
spelling against registry and remove any extra text
IPv6 in IPv4 parcr1.fr.ndsoftwarenet.net ->
user-212-88-249-12.tvcablenet.be WOOF BGP4+
*** WOOF: Destination site does not appear in registry - check spelling
against registry and remove any extra text
IPv6 in IPv4 parcr1.fr.ndsoftwarenet.net -> tms.dicp.de DICP BGP4+
*** DICP: Destination site does not appear in registry - check spelling
against registry and remove any extra text
IPv6 in IPv4 parcr1.fr.ndsoftwarenet.net -> 194.139.3.28 DE-TRMD BGP4+
*** DE-TRMD: Destination site does not appear in registry - check spelling
against registry and remove any extra text
IPv6 in IPv4 parcr1.fr.ndsoftwarenet.net -> pc65.bydgoszcz.sdi.tpnet.pl
MUSIALEK STATIC
*** MUSIALEK: Destination site does not appear in registry - check
spelling against registry and remove any extra text
IPv6 in IPv4 parcr1.fr.ndsoftwarenet.net -> thunderbird.e-concepts.be
ERALY STATIC
*** ERALY: Destination site does not appear in registry - check spelling
against registry and remove any extra text
IPv6 in IPv4 parcr1.fr.ndsoftwarenet.net -> mirror.seabone.net CACI BGP4+
*** CACI: Destination site does not appear in registry - check spelling
against registry and remove any extra text
IPv6 in IPv4 parcr1.fr.ndsoftwarenet.net ->
port5.ds1-sby.adsl.cybercity.dk FABBIONE BGP4+
*** FABBIONE: Destination site does not appear in registry - check
spelling against registry and remove any extra text
IPv6 in IPv4 parcr1.fr.ndsoftwarenet.net -> 212.81.112.99 DARKSNOW BGP4+
*** DARKSNOW: Destination site does not appear in registry - check
spelling against registry and remove any extra text
IPv6 in IPv4 parcr1.fr.ndsoftwarenet.net -> ipv4.nerime.net NERIME BGP4+
*** NERIME: Destination site does not appear in registry - check spelling
against registry and remove any extra text
IPv6 in IPv4 parcr1.fr.ndsoftwarenet.net ->
pa76.miedzyrzec-podlaski.sdi.tpnet.pl EXORCIST STATIC
*** EXORCIST: Destination site does not appear in registry - check
spelling against registry and remove any extra text
IPv6 in IPv4 parcr1.fr.ndsoftwarenet.net -> quint.netisland.net TOREN
STATIC
*** TOREN: Destination site does not appear in registry - check spelling
against registry and remove any extra text
IPv6 in IPv4 parcr1.fr.ndsoftwarenet.net -> chabrowa.net CHABROWA STATIC
*** CHABROWA: Destination site does not appear in registry - check
spelling against registry and remove any extra text
IPv6 in IPv4 parcr1.fr.ndsoftwarenet.net -> pa1.wroclaw.sdi.tpnet.pl
ANDRE-WRO STATIC
*** ANDRE-WRO: Destination site does not appear in registry - check
spelling against registry and remove any extra text
IPv6 in IPv4 parcr1.fr.ndsoftwarenet.net -> b1rtr.cyf-kr.edu.pl CYFRONET
BGP4+
*** CYFRONET: Destination site does not appear in registry - check
spelling against registry and remove any extra text
IPv6 in IPv4 parcr1.fr.ndsoftwarenet.net -> 212.49.128.151 BTIGNITE BGP4+
*** BTIGNITE: Destination site does not appear in registry - check
spelling against registry and remove any extra text
IPv6 in IPv4 parcr1.fr.ndsoftwarenet.net -> br2.den1.amisp.net AISP BGP4+
*** AISP: Destination site does not appear in registry - check spelling
against registry and remove any extra text
IPv6 in IPv4 parcr1.fr.ndsoftwarenet.net -> ipv6.asol.com.ph ASPI-PH BGP4+
*** ASPI-PH: Destination site does not appear in registry - check spelling
against registry and remove any extra text
IPv6 in IPv4 parcr1.fr.ndsoftwarenet.net -> ns1.labatut.net LABATUT BGP4+
*** LABATUT: Destination site does not appear in registry - check spelling
against registry and remove any extra text
Part of properly maintaining _YOUR_ ipv6-site object is making sure that
you don't reference an object that doesn't exist. If someone is unable or
unwilling to create & maintain an ipv6-site object, do you really feel
that they are a good peering candidate? I certainly don't.
Last but not least:
(13) Just for my own personal amusement... You have a VPI/VCI pair field
in your list of public peering points that you participate in or plan to
participate in on your website but, your interconnects are all listed as
100M FE. Um, what kind of ethernet are you using that supports VPI/VCI or
did you just think it would look "cool" to have that field?
Nicolas, I spent quite a bit of time and effort composing this email and I
feel that I have asked valid questions of you. Please answer them
concisely and accurately.
---
John Fraizer | High-Security Datacenter Services |
President | Dedicated circuits 64k - 155M OC3 |
EnterZone, Inc | Virtual, Dedicated, Colocation |
http://www.enterzone.net/ | Network Consulting Services |