[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

6Bone Mail

 In your previous mail you wrote:

   > From: Francis Dupont <[email protected]>
   > => there are three solutions for the dynamic routing of the 6 bone:
   >  - RIPv6 but RIPv6 doesn't scale (remember DVMRP) and is not specified
   >  for the usage over tunnels.
   How come? Why should RIPv6 work differently over tunnels?

=> it is not clear if a tunnel is an interface (with what kind
of properties) and RIPv6 doesn't manage half connectivity.
DVMRP is a distance vector routing protocol with special hooks
for tunnel and is not the good solution for the Mbone.
I believe we should avoid the same error...

   As I see it, tunnel is just an instance of 'normal' point-to-point interface.

=> have tunnels link-local addresses (interface => link-local address
according to RFCs) ? Are tunnels point-to-point or NBMA ?
How the "multicast" is done on tunnels ? It is not so clear.

   The fact that IPv6 packets are encapsulated into IPv4 frames at
   link layer should not matter at network layer.  Do you tweak
   your network protocols for each meadia it may run over?  I don't.

=> RIPv6 is specified for LANs (in the mind of its authors).

   Here at Bay we have a generic RIPv6 implementation which runs over tunnels
   as specified -- the same way it runs over other types of links.
=> do you detect half tunnels ? Do you aggregate prefixes ?
RIPv6 is a cheap solution but I am not convinced it is the best
today, NHRP is a good candidate too.

   NHRP is not a routing protocol.  Are you proposing to confine 6bone
   to a single LIS so no routing would be necessary?
=> yes because we have a global connectivity on the Internet
then no intermediate routers are needed between clouds...
We need NHRP for other NBMAs too.

   > PS: perhaps we should create a 6bone IETF WG or to resume the TACIT WG
   > (one of the T of TACIT are for "tests" :-) ?

=> I still think we need a WG for the future of 6bone
(and not mix it with immediate operational issues).


[email protected]