San Jose IETF 6bone BOF minutes

[Bob Fink LBNL]

IETF Secretariat,

I've enclosed the minutes of the San Jose IETF 6bone BOF.

Though I handed in some slides at the reg desk in San Jose to be included
in the printed proceedings, I would like to cancel them.  The material I
handed in, as well as other relevant info, is provided within these minutes.


Thanks,

Bob


_______________________cut here_______________________________________


6bone BOF Meeting
December 10, 1996
San Jose, CA

Bob Fink / LBNL, Chair
Reported by Alain Durand, Pedro Roque, and Bob Fink.

--------------------------------------------------------------------
Agenda
--------------------------------------------------------------------

1. Introduction and Agenda Bashing / Bob Fink (5 mins)
2. Formation of a 6bone WG - do we? / Bob Fink (10 mins)
3. If so, what might we set as an initial WG goal? / Bob Fink (5 mins)
4. Topology  / Alain Durand (30 mins)
5. Addressing / (30 mins)
6. Routing / Pedro Roque (15 mins)
7. RIPE Registry cleanup & changes / David Kessens (15 mins)
8. Maps / Bob Fink (5 mins)

--------------------------------------------------------------------
1. Introduction and Agenda Bashing / Bob Fink
--------------------------------------------------------------------

Bob Fink convened the meeting, and reviewed the agenda and its order,
asking for changes.  Rough time estimates were allocated for each item to
keep the meeting on track.  The agenda was acceptable to the group and the
meeting continued.

Fink noted that there was a 6bone web page at:

	http://www-6bone.lbl.gov/6bone/

and a mail list that one can subscribe to:

	majordomo@isi.edu

	subscribe 6bone

--------------------------------------------------------------------
2. Formation of a 6bone WG - do we? / Bob Fink
--------------------------------------------------------------------

Bob Fink presented his view of the pros and cons of forming a working group.

Advantages:

  - getting a meeting place at IETF meetings

  - formalization of process of feedback to other IETF ipv6 efforts

Disadvantage:

  - need a goal and some work products

  - need to incur administrative overhead

Fink contended that we've already succumbed to the admin. overhead and have
most processes in place because of the existing 6bone testbed effort, and
that 6bone participants are already producing useful products.  Thus we
(the 6bone participants) may just need to document some of them.  Thus Bob
concluded that it was worth forming a working group.

Fink also presented a possible draft charter:

The 6bone Working Group is a forum for information concerning the
deployment, engineering, and operation of ipv6 protocols and procedures in
the global Internet. This activity will include, but not be limited to:

  - Deployment of ipv6 transport and routing in the global Internet via a
    "6bone" testbed to assist in the following.

  - Creation of "practice and experience" informational RFC documents that
    capture the experiences of those who have deployed, and are deploying,
    various ipv6 technologies.

  - Feedback to various IETF ipv6-related activities, based on testbed
    experience, where appropriate.

  - Development of mechanisms and procedures to aid in the transition to native
    ipv6, where appropriate.

  - Development of mechanisms and procedures for sharing operational
information
    to aid in operation of global ipv6 routing.

Fink noted that the 6bone, though originally formed from the model of the
mbone, was not like the current Mboned WG effort as the early 6bone is not
a real start at deployment, rather a testbed for developers and users to
try out implemenations and operational experiences to feed back into IPng
IETF efforts and also provide advocacy for IPv6 deployment.

There was broad consensus that Fink should proceed with forming a working
group.  There were also comments that supported Bob Fink acting as the
chair, which he agreed to do at least initially for the formation effort.

--------------------------------------------------------------------
3. If so, what might we set as an initial WG goal? / Bob Fink
--------------------------------------------------------------------

Bob Fink then presented several possible work products of a working group
that were basicallyt generating a series of informational RFCs:

  - documentation of the RIPE registry

  - documentation of 6bone testbed participation procedures

  - documentation of relevant experiences with the testbed

It was noted that currently the 6bone effort would be under the Operations
area (Bradner/O'Dell are directors).  Bob Fink agreed to proceed with
filing the necessary charter and plan with the area directors as well as
generating a discussion of the charter on the mailer.

--------------------------------------------------------------------
4. Topology / Alain Durand
--------------------------------------------------------------------

Alain Durain proposed converting the 6bone testbed topology to a three
level system of core backbone routers, second tier transit routers and leaf
routers (for node sites not doing transit).  He proposed this to better
structure the 6bone for effective routing and to simplify its topology.
Tunnels could then be built for either production or experimental uses.

Durand noted his main point is that tunnels are per nature layer 2 items,
and that if one wants the 6-bone to grow, it needs to do some kind of
routing.  From hiss experience, it's not such an easy task and probably not
all nodes are willing to do it completely. Thus the reason for his proposed
reorganized routing/topology into a three level system.

It was agreed to continue this discussion on the mailer.

--------------------------------------------------------------------
6. Routing / Pedro Roque
--------------------------------------------------------------------

Pedro Roque led off a discussion of routing in the 6bone with his concern
that RIPng was slow to converge and caused him much trouble on the less
reliable trans-Atlantic links.

Others expressed their opinion that RIPng was able to converge and work in
the 6bone.  It was clear that there was a need for lively debate on the
relative merits of routing approaches for the 6bone.

The chair suggested that it was best to pursue this on the mailer.

--------------------------------------------------------------------
5. Addressing
--------------------------------------------------------------------

Alain Durand presented his request for a change in the prefix notation for
IPv6 addressing (draft-durand-ipv6prefix-00.txt).  It was agreed that this
was an oversight in RFC 1844 specifying address notation, and that this
topic should be brought up at the IPng meetings this IETF week (it was and
there was agreement there to incorporate Alain's suggested prefix format).

Durand noted that this is not a "change" per se, just something that is not
standardized yet.

Someone pointed out that this notation could conflict with another notation
that was used by the RPS group. Durand checked this with them later after the
meeting, and thinks that in fact there is no problem at all.

Pedro Roque presented his suggested address allocation policy for use in
the 6bone.  This was an elaboration of RFC 1897 that basically suggests
that for leaf nodes (in the 6bone) that the prefix should be constructed
using the first 32 bits of the prefix used by the transit site they are
connected to.

Some thought this was a reasonable idea.  Geert Jan de Groot said that this
was maybe not necessary because a dynamic routing algorithm would solve
most problems.

The discussion went back to RIPng, with some saying that RIPng is maybe not
enough, and that what is needed are better protocols like BGP or IDRP.

The question was raised about sites connecting to "big" nodes, and which
prefix they should use. The answer was both, as it's a case of multihoming.

Matt Crawford proposed using the 6bone testbed to experiment with Mike
O'Dell's 8+8 addressing proposal.  He identified various issues relating to
this effort:

  - Host issues - modified pseudo header checksum for 8+8 addresses

  - Router isssues - insertion of RG

  - DNS issues
    - DNS lookup in 2 different parts AA & RG
    - Discover bootstrap troubles

  - Security issue - should we mandate IPsec?

It was noted that IPsec is not currently in the tested.

Jim Bound noted that a new draft was needed to explain what the differences
are with the present addressing implementation.  Jim also noted that he was
interested in attempting an implementation of 8+8 that co-existed with the
existing addressing as he believes that can be done.

Bob Hinden expressed his concern that until the IPng working group decided
if 8+8 was possible that it was premature for the 6bone efforts to deal
with it.  The chair agreed with this concern but also noted that the 6bone
effort might assist the IPng 8+8 design effor in giving feedback as it
moved along.

It was agreed to continue discussion of possible 6bone 8+8 efforts on the
mailer.

--------------------------------------------------------------------
7. RIPE Registry cleanup & changes / David Kessens
--------------------------------------------------------------------

David Kessens presented the RPSL work in relation to a modified format for
the RIPE-NCC 6bone routing registry. He contended that a well defined (and
new) syntax was necessary before cleaning up the current RIPE-NCC 6bone
registry.

There were some comments on various fields.  It was noted that an IPv6 end
point address should be added.

It was agreed to continue the discussion on RIPE-NCC 6bone registry
restructuring on the mailer.

David's presentation is available at:

	http://www-6bone.lbl.gov/6bone/ripev6object-kessens.ps


--------------------------------------------------------------------
8. Maps / Bob Fink
--------------------------------------------------------------------

Bob Fink noted that he was at the useful limits of the current 6bone
diagram, but that he intended to experiment with other forms of drawing it
as the topology discussions and restructuring proceeded.

The preferred solution would be to have the maps drawn automatically from
registry data.  Until such mechanisms are in use for the 6bone, Fink noted
that he was willing to try to keep a 6bone map up to date manually.

--------------------------------------------------------------------
--------------------------------------------------------------------
- end