[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
retransmit of: 6bone pTLA assignment rules
- Subject: retransmit of: 6bone pTLA assignment rules
- From: [email protected] (Bob Fink)
- Date: Fri, 06 Feb 1998 09:55:50 -0800
I am increasingly finding myself in the dilemma of being asked to assign a
pTLA, and then having to decide what is/is not appropriate. This email is
my attempt to get exposure of the issues and help in deciding an
appropriate course of action in assigning pTLAs.
Let me start by saying that the creation of pTLAs is getting
morecontentious as some believe that we should not create them so easily.
I'm also sure that all of us believe that we must start forging the 6bone
backbone into a reliable transport for ipv6 use and testing.
Having said that we (at least me) need to have some criteria for assigning
pTLAs. I'll see if I can characterize the criteria I have been using lately.
1. Must have experience with IPv6 in the 6bone, at least as a leaf site and
preferably as an NLA transit under a pTLA.
2. Must have the ability and intent to provide "production-like" 6bone
backbone service to provide a robust and operationally reliable 6bone
3. Must have a potential "user community" that would be served by becoming
a pTLA, e.g., the requester is a major player in a region, country or focus
4. Must commit to abide by whatever the 6bone backbone operational rules
and policies are (currently there are no formal ones, but the Alain Durand
draft is a start in trying to define some).
To date, when I've explained the above (admittedly not so formally stated
as above) there is typically one of two results. The first is that the
requester goes away and studies more, becomes a leaf site, or forgets the
6bone, etc., that is basically doesn't persist in asking for a pTLA. The
second is that the requester comes back with strong statements of why it is
important to them, stating that they still want a pTLA assigned. In the
latter cases I will assign a pTLA (after all, I'm no absolute authority on
any of this).
So, having said all this, I would like to propose a change to this process.
In particular I would like to publish the request along with the
requester's response to the above criteria, and get feedback from the 6bone
mail list (not just the other pTLAs). Then I would make the final call
based on what I think approximates "rough consensus".
To this end I am enclosing a request for a pTLA from British Telecom Labs
(BT-LABS) and their response to these questions. I would like responses to
the list on both the process I propose and the BT-LABS request iteself.
From: Stuart Prevost <[email protected]> To: "'Bob Fink LBNL'"
<[email protected]> Subject: Request for pTLA for BT LABS/UK Date: Mon, 2 Feb
1998 15:53:45 -0000
I am writing to request a pTLA on the 6bone, as you know we have been a
leaf site for a year now. During this time we have gain valuable
experience in IPv6, and have developed a large site here in the UK. We
use Cisco routers which currently connect to NRL using BGP4+, in
becoming a backbone site we feel that we can gain additional experience
to the benefit of the IPv6 community.
BT LABS has also formed links to Telenor R&D in Norway. As part of this
work both companies have a research interest in IPv6. As part of this
collaboration we plan to create a native IPv6 link to them using the
JAMES ATM network. I also understand from Tony Dann who attends the
IETF meetings this will help in the plans to build a Native IPv6 network
If you require any additional information before issuing a pTLA please
let me know.
From: Stuart Prevost <[email protected]> To: "'Bob Fink'"
<[email protected]> Cc: Tony Dann <[email protected]> Subject: RE:
Request for pTLA for BT LABS/UK Date: Wed, 4 Feb 1998 10:23:12 -0000
Thanks for your response, we don't mind being a test case in helping to
resolve the issues of criteria for backbone sites. We agree that the
6bone backbone should evolve into an appropriate infrastructure for true
IPv6 evaluation. Therefore the response to your criteria for pTLA
assignment is as follows.
>>1. Must have experience with IPv6 in the 6bone, at least as a leaf site and
>preferably as an NLA transit under a pTLA.
BT LABS has been a participating in the 6bone global experiment since
January 1997. In that time we have acted as a leaf site from NRL and
most recently as a NLA transit site providing connectivity to the 6bone
for Telenor R&D.
>>2. Must have the ability and intent to provide "production-like" 6bone
>>backbone service to provide a robust and operationally reliable 6bone
BT LABS is the research arm of BT plc, which already has an ISP business
division. We therefore have the skills to provide a "production like"
service. We understand the value of the 6bone experiment and intend to
actively participate in all initiatives which act to increase
understanding of future IPv6 service issues.
>>3. Must have a potential "user community" that would be served by becoming
>>a pTLA, e.g., the requestor is a major player in a region, country or focus
BT is a major player in Europe and therefore has a large potential user
>>4. Must commit to abide by whatever the 6bone backbone operational rules
>>and policies are (currently there are no formal ones, but the Alain Duran
>draft is a start in trying to define some).
We fully commit to this and welcome progress with Alain Durand draft.
Hope these answers are appropriate and we have no problem with you
publishing this request to the list. We hope that by starting this off
that your task will be made easier when assigning pTLA.
=======from the 6bone registry
descr: Martlesham Heath
location: 52 03 52 N 01 17 16 E 0m
application: ping gate.ipv6.bt.net
tunnel: IPv6 in IPv4 gate.ipv6.bt.net -> guar.ipv6.nrl.navy.mil
tunnel: IPv6 in IPv4 gate.ipv6.bt.net -> gate6.lancs.ac.uk ULANC
tunnel: IPv6 in IPv4 gate.ipv6.bt.net -> mbone-eir.nta.no
remarks: Experimental IPv6 evaluation network
remarks: DNS operational for forward and reverse zones
remarks: Primary DNS dns.ipv6.bt.net
remarks: Reverse (.18.104.22.168.0.1.0.F.E.F.F.3.IP6.INT)
remarks: ipv6-site is operational since 30-Jan-97
changed: [email protected] 19971030