Re: Questions about tunneling proposals

[James Stepanek <stepanek@antares.aero.org>]

Hi,

  I've made a couple of comments in response to traffic on the list.  I
  would also like to raise an issue.  Is there a consensus to evolve
  the VIPRe document submitted by steve and myself,
  <draft-stepanek-vipre-00.txt> under the auspices of the UDLR working
  group?  Right now it's an individual submission, but if there is
  sufficient interest, I would like to move it over eventually.

  There was also talk about unification of terms.  Although, I don't
  think the terms are too divergent, I would certainly advocate using
  any terms as long as they are consistent.  The reason we used
  "satellitey" terms like "uplink" and "downlink" originated in our
  relative ignorance of the critical problems of unidirectional links
  in other types of networks--we didn't want to make presumptions about
  the problmes our approach solves.  It would be great if others could
  give us feedback regarding the applicability of this approach to
  other types of networks with unidirectional links.  Clearly, having a
  single solution for all domains is ideal, but we need to include the
  smart people in the various domains to make sure we do things right.

have a nice day,

james

> From owner-udlr-m@chouette.inria.fr Tue Mar 25 10:55:45 1997
> Date: 	Tue, 25 Mar 1997 10:43:22 -0800
> From: Stephen Schwab <schwab@twinsun.com>
> To: udlr@sophia.inria.fr
> Subject: Re: Questions about tunneling proposals
> 
[...]
> This is not the case for the VIPRe implementation.  VIPRe provides a tunnel
> to carry encapsulated IP packets.  We don't restrict to RIP or OSPF packets.
> (James, please correct me if the implementation has changed recently to
> restrict which packets traverse the reach-back network as encapsulated vs.
> non-encapsulated packets.)

  This is absolutely correct, and even if an implementation did
  restrict traffic, I would resist mentioning that specificly in the
  draft.  Instead, I would advocate text making clear the notion that
  not all traffic sent out a unidirectional interface of the receiver
  is necessarily relayed back to the feed.  One paragraph on page 9
  talks around this notion, but it certainly could use some
  crystallization.

     "The correct choice of encapsulation protocol depends upon the
     nature of network. Important considerations include security and
     bandwidth management of bidirectional links, as well as the
     expected number of participating downlink nodes."

  Its our intention that the relay provides complete bidirectionaly
  link semantics, and that restrictions upon the use of that link be
  dealt with as part of a policy addressed elsewhere.  Mechanisms for
  these restrictions could very well be part of the same system
  providing the bidirectional link semantics, but they ultimately
  serve a different purpose.

[...]
> p.s. My return address is schwab@twinsun.com.  Mail is forwarded from
> schwab@aero.org.

  If you are getting mail with the wrong address, it's probably my
  fault.  I put the wrong address on the header of the draft!  I got
  the right one in the "Author's" section though.

> 
> From owner-udlr-m@chouette.inria.fr Thu Mar 20 09:17:07 1997
> X-Authentication-Warning: pax.inria.fr: Host mistigri.inria.fr [138.96.24.79] claimed to be mistigri
> Date: 	Thu, 20 Mar 1997 08:56:03 -0800
> From: Thierry Ernst <thierry.ernst@sophia.inria.fr>
> MIME-Version: 1.0
> To: udlr <udlr@sophia.inria.fr>
> Subject: Questions about tunneling proposals
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline; filename="questions"
> 
> Hello,
> 
> I have recently joined this mailing list.  I'm currently working on UDLR for
> Inria.  After sorting out the different ideas in the proposals, I think
> a few questions covering various points are relevant.
> 
[...]
> *******************************************************************************
> 
> 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.

  In this case, the configuration of routing protocols will depend upon
  the implementation of the protocol.  As far as I can tell, most
  routing protocols in common use include a notion of "weighting"
  particular links.  So it becomes a matter of finding the correct
  knobs on the implementation to affect the weight on the "return"
  direction of the virtual link.