6bone Prequalification for Sub-TLA assignment

[Robert Rockell]

->This will be open for discussion until 19 April '99, at which time the IAB,
->RIRs and IPv6 co-chairs will decide whether to move forward on an agreement
->about this or not, based on comments received. 

If the 6bone Hardening effort is not fully developed yet, maybe we can hold
off on the date to see if the efforts of this group prove to be fuitful, or
at least agreed upon, by all interested parties? However, this is not meant
to say that we should hold up the delegation of TLA's till after Oslo,
simply due to scheduling. 

I am afraid to move forward with the assumption that the hardening effort
will be written in stone, and used as an advisory to the registries, if it
has the chance of not being widely accepted withing the working groups, and
particualarly the 6bone. 

Just a humble opinion.

Rob Rockell
Sprintlink Operations Engineering
703.689.6322
800.724.3508; 3858833

->
->
->Thanks,
->
->Bob
->
->------------------
->6bone Prequalification for Sub-TLA Assignment - draft 2, April 4, 1999 -
->Bob Fink
->
->The following is a draft to describe how the 6bone might be used as a
->prequalification step during the "bootstrap" phase of Sub-TLA assignment by
->the Regional Internet Registries (RIRs):
->
->It is predicated on the following facts:
->
->F1. the 6bone community represents the world-wide IPv6 operational
->networking community as of early 1999, including all existing IPv6
->providers and users in the world, operating under the only IPv6 address
->allocation and authority in place at that time, i.e., the 3FFE::/16
->allocation to the 6bone under RFC 2471 ("IPv6 Testing Address Allocation")
-><ftp://ftp.isi.edu/in-notes/rfc2471.txt>.
->
->F2. the 6bone has a well defined address structure underneath the RFC 2471
->allocation for high-level (top tier) transit service providers, know as a
->Pseudo-TLA (pTLA), that all the known top level IPv6 transit providers are
->part of. See <http://www.6bone.net/6bone-testv2-addr-usage.html> for
->documentation of the pTLA structure. The pTLA structure is modeled on the
->TLA structure and serves as a proving/testing ground for those structures. 
->
->F3. the 6bone process for becoming a Pseudo-TLA (pTLA) is well defined and
->accepted by the 6bone community. See
-><http://www.6bone.net/6bone-routing-practice.htm> Section 7 for Guidelines
->for 6Bone pTLA sites. It has just been made Informational RFC 2546.
->
->F4. the 6bone community as a whole is willing to provide their knowledge,
->experience and opinions as part of a process to help "bootstrap" the
->Sub-TLA (sTLA) address allocation process for the RIRs.
->
->===
->6bone Prequalification for Sub-TLAs 
->
->S1. the sTLA requestor (sTR) places their Sub-TLA request with the
->appropriate RIR and declares that they intend to use the 6bone
->prequalification process (6PP).
->
->S2. the sTR (and the RIR?) notifies the 6bone list of their intent to use
->the 6PP.
->
->S3. the sTR follows the published process for becoming a pTLA (This will
->change by the end of the OSLO IETF meetings as the 6bone hardening process
->is approved by the NGtrans 6bone community). At the present time this
->process is documented by [RFC 2546] Section 7. This process currently
->requires 2-3 months minimum, based on this current practice, from the time
->of first joining the 6bone as a end-site network.
->
->S4. after the sTR has been approved as a pTLA, and operating as a pTLA for
->3 months with at least y customers (either lower level transits or
->end-sites) (recommend 3 customers), the pTR petitions the 6bone mailing
->list for support of its request for a Sub-TLA based on its performance as a
->pTLA, providing relevant proof or statement of how and/or why they believe
->they have met current 6bone backbone practices (currently as in RFC 2546).
->
->S5. a 6bone steering group (consisting of 3-5 persons established by 6bone
->participant consensus) prepares a short 6bone fitness report report (6FR)
->based on input received from 6bone participants (note this means members of
->pTLAs, pNLAs or end-sites organizations, not just mailing list subscribers)
->and factual information of compliance with established pTLA rules extant at
->the time (currently RFC 2546) and submits this report (the 6FR) to the
->appropriate regsitry (will need a well established contact point for the
->three IRRs).
->
->S6. if after the minimum time for the steps above, plus 1 (2?) month(s),
->the sTR may protest to the appropriate RIR of non-responsiveness and revert
->to another qualification process per RIR rules (unrelated to the 6PP).
->
->S7. after assignment of an sTLA to the sTR (by the RIR), the sTR may
->optionally renumber from the 6bone pTLA prefeix to the sTLA prefix, or
->continue use of their pTLA. If the pTLA space becomes over subscribed, the
->most likely networks to be asked to surrender their pTLA would be those
->holding production number space.
->
->===
->Misc. Notes:
->
->N1. currently the RFC 2546 doc is being reworked under the 6bone hardening
->process now underway, which will almost certainly yield a stronger set of
->rules on what it takes to become a pTLA.
->
->N2. the current RFC 2546 doc does not specify a prequalification time as a
->pNLA or end-site 6bone site prior to requesting a pTLA, so it is
->recommended that a minimum of 2 months be specified (prior to the new rules
->being published after Oslo).
->
->N3. in S6. above, the total time from start of the 6PP until a protest
->could be made to the RIR, would be in the 6-8 months minimum (2-3 mos.
->while becoming a pTLA, 3 mos. while a pTLA, plus 1-2 mos.).
->
->N4. we need a way to handle existing pTLA sites that should not really have
->an sTLA as they are not production networks, rather they were created to
->"bootstrap" the 6bone or help a specific testing user community. This might
->include sites like INNER, TELEBIT, VIAGENIE, CISCO, NRL, UO, 3COM, MERIT,
->BT-LABS. Note that DIGITAL (now COMPAQ) is different in that they are
->acting as a real IPv6 exchange thus have not been included in the previous
->list. It is doubtful that these site would ask, but if they did it would be
->unlikely they could get a positive 6PP Report. So maybe the problem should
->be ignored and let the 6bone community police itself on this.
->
->N5. clearly this process will be none too quick between the time to get it
->firmed up and agreed to and the inherent time built into the process as
->described above. Thus it may get poor support if the revised RIR draft
->offers a reasonable alternative (of course that's why I noted this was a
->voluntary path for sTRs to take). On this we will have to see what the RIRs
->do in their next draft.
->
->N6. there may be a liability exposure of the IETF with this process, given
->the 6bone relationship to the IETF. This need not be covered here, but
->everyone should be aware of the issue.
->
->
->Things forgotten !!?? :-) Speak up!
->
->-end
->
->