6bone Routing Registry

[David Lee]

Bob and I were discussion how to list internal sites, or internal nodes within
a site.  For example, VT-EE, VT-BEV, etc. are considered nodes within the 
VT IPv6 AS.  They are all under the same prefix and same regulatory 
policies.  We were in the general agreement that the registry should only list
sites as opposed to internal sites/nodes.  Thus, VT-EE would not get a
separate registry entry but can show up on the VT registry entry.  However, 
there's some merit to having separate entries, so I'm putting this out for 
comments.  Bob, feel free to step in anytime you want. :)

Additionally, I'm expecting to get some native IPv6 routed subnets up for 
testing and there appears to be no way to designate this in the current RIPE 
registry format.  First off, there is some question of whether or not to even 
designate this.  Assuming that we want to designate it, which I would think 
that we would, then, I would think that the format needs to be the same as the 
tunnel designation.  Thus, I would proposed the following.

native:   [iif addr] [oif addr] [other site] [rp type] [status] {type}

where:

iif ipv4 - Address of the routed subnet for the router's input interface address
oif ipv4 - Address of the routed subnet for the outgoing interface
    site - Outgoing interface site name
 rp type - Routing protocol type.  RIPng, static, etc.
  status - One of the following:
           oper/u "operational" status and link up
           oper/d "operational" status (or was ;) and link down
           expr/u "experimental" status and link up
           expr/d "experimental" status and link down
    type - Optional field of the format XY, where X is one of:
           u - feed to a upstream site
           d - feed to a downstream site (which may or may not be a leaf)
           t - feed to a "lateral" transit site (e.g., other backbone)
           l - feed to a downstream leaf site
           And Y is a number from 1 to 9, where 1 designates a primary
           feed, 2 designates a secondary feed, and so forth. 

An example of a machine with two interfaces would be:

native:	128.173.88.118 128.173.89.100 VT-EE-NETLAB RIPng expr/u l1

I was also thinking of including the routed subnet's IPv6 prefix but I think
that's unnecessary information.  The going assumption is that the routed
subnet's prefix is some portion of the destination site's prefix.  I would 
also advocate that internal sites/nodes be listing according to the format 

	[registry entry]-[internal name]

I would note that if we start to match the production IPv4 network, then
we'll have many of these native entries.  When (and not if ;) we get to that 
point, I would propose that we only list the border router(s) for the native 
routed site.  One of the justifications for having native routed nodes listed 
now is for people to see how many of these we actually have.  This gives us an
idea of penetration and can also be used on a marketing side.  When we
have a significant amount of sites that are native routed, the technical
information need is reduced and we also have a much different and stronger 
selling point on IPv6 rollout.

The only thing that differs from standard practice is the feed type.  
I believe that the feed type information will help people get a better 
understanding of how a site is connected.

I would, naturally, advocate that the tunnel registry information 
(http://www-cnr.lbl.gov/6bone/6bone-register.html) be changed to 
1) reflect standard convention and 2) include the proposed feed type
information.  Thus, the format should be:

tunnel:   [source addr] [dest iaddr] [site] [rp type] [status] {type}

Regards,
DCL

-- 
David C. Lee, EE PhD student - http://www.visc.vt.edu/~dlee - dlee@vt.edu
PHONE: 1-540-231-8398 | FAX: 1-540-231-3362 | LOCATION: 475 Whittemore Hall
Virginia Tech Information Systems Center, Blacksburg, Virginia 24061-0111