Re: Dynamic tunneling, multicast and terms unification

[ygz@isl.hrl.hac.com (Yongguang Zhang)]

Thierry Ernst writes
> Some of those working on a solution based on tunneling have raised a
> need for dynamic tunneling.  At the time being, this topic was under
> consideration and further work was needed.  Has anyone made any progress
> in the area ?  I would welcome any suggestion about that particular
> point.

About dynamic tunneling.  We can mention in the draft that the virtual
network should behave very like a normal bidirectional network so that
most existing software works.  One requirement is that the error
assumption should be the same -- if one direction goes down, so should
the other direction.  Details on how to implement that in virtual 
interface are left to implementors.


> Another area I'm interesting in is multicast.  Could Yongguang Zhang
> give any explanation about the term "multicast tunneling" that appear in
> his web page (part "Asymmetric routing in the Internet")?    

When we have a unidirectional network (e.g., a satellite broadcast network),
it is possible to have multicast feeds (e.g., big uplink centers).  All
feeds have full connections to the Internet and can provide IP forwarding
to all receivers.  This is equivalent to an Ethernet with multiple 
gateways to the Internet.   To emulate this environment, we use multicast
tunnelling to facilitate the multicasted routing information from a receiver
to the set of feeds.  How is it scalable?  It is the problem of the IP
multicast routing, not UDLR.  I guess, if the number of feeds is small
and the feeds are fixed, the per source flood-and-prune DVMRP may not
be efficient.  CBT should be better.  Agree?


Stephen Schwab writes
> How many of those reading this list have actually used their implementations
> over a satellite link?  (Or a one-way cable distribution tree?)

DirecPC has been using tunneling since 2 years ago, but dynamic routing is
never turned on.  We (in HRL) only tried our tunneling approach in a small
testbed.


About tunneling RFC.  We won't reinvent new tunneling protocol.  In fact
I don't think any of our tunneling approaches depend on the specific
tunneling specification.  We can use any one, if there is one that IETF
agrees upon (and it meets service providers' security requirements).


We'll have our WG meeting next Tue morning.  We don't seem to have a schedule
yet.  Any one who plan to present please post to the mailing list?


Yongguang