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

Re: Questions about tunneling proposals




Thierry Ernst <thierry.ernst@sophia.inria.fr> writes

> Since this setting is static, I wonder which cost is chosen and how, and
> which metric is used.  If the metric is hops count the setting of
> interface "if0" of the feed to a lower cost seems quite  natural, whereas
> setting interface "if0" of the receiver to a higher cost in order to 
> avoid traffic over the tunnel doesn't seem straightforward.  How do you 
> proceed?

This is what I use in gated.conf for RIP (I never tried OSPF).

At feed:

        export proto rip {
                proto direct {
                        x.x.x.x metric 15;      # downlink network addr
                } ;
        } ;

At each receiver:

        export proto rip {
                proto direct {
                        host y.y.y.y metric 1;  # uplink host addr (tunnel)
                } ;
        } ;

Selecting the right metric is probably an improtant issue
that we should address in the draft.  I use 16 in RIP --
RIP packets are flowing in the UDL and no route is installed
at the receive -- exactly what we need.


> How is topology change taken into account?

Some link-level trick can be used to determine changes in
UDL connectivity.  For example, the receiver can monitor the
UDL link status.  Whenever the UDL link is down, the virtual
interface should stop sending data to the feed via the tunnel.
Then the feed can know that the (virtually bidirectional) link
is down.

If we agree this is a simple working solution, we can add it
to the draft too.

> Second, concerning AEROSPACE's internet draft <draft-stepanek-vipre-00.txt> 

> Ok, you say protocols will have to be configured to reflect the high cost
> of the virtual IP hop.  But how do you do it?  Otherwise questions mostly 
> are the same as the ones for Wide.  It seems both solutions are close.

Yes they are close, and so is our virtual symmetric network approach
in HRL.

> In both proposals there is a virtual reverse link to elude routing
> protocols as if there were a bidirectional satellite link.  The real
> difference I can see is that Aerospace is going deeper in the level of
> abstraction.  Only routing traffic is using this virtual reverse satellite
> link in Wide's proposal.  What about Aerospace?  I guess all traffic from 
> receivers to feeds isn't encapsultad, but I don't see this point anywhere
> clearly addressed in the draft.  Could you have a word about that?

Agree.  It should be explicitly mentioned in the draft that the tunnel
is used for routing protocol messages only.


Another issue, how should we unify the terms?  Feed and receiver?
Uplink and downlink?  What is the best word to denote the host
at the sender end of the UDL and what is the best to denote the
other end?

Yongguang

==============================================================================
Yongguang Zhang, Ph.D., Research Staff Member (Computer Science)
Hughes Research Laboratories, RL-96, 3011 Malibu Canyon Road, Malibu, CA 90265
E-mail: ygz@isl.hrl.hac.com                                phone: 310-317-5147
URL:    http://www.wins.hrl.com/people/ygz                   fax: 310-317-5695