Re: Tunneling vs routing protocol modification

[stepanek@antares.aero.org (James Stepanek)]

hi folks,

  I think Walid outlined a bunch of the important issues, and I have a
  few comments.  First, I'd like to qualitatively discuss the issue of
  "rmp vs relay approaches" at a high-level, considering the
  differences.

    o I like the rmp approach because it deals with the problem
      directly, i.e., it specifies a link as unidirectional and does
      the right thing depending upon the routing protocol in use.  In
      contrast, the relay approach is sneakier.  It solves the problem
      by semanticly dissolving it.  This means network designers and
      maintainers must remain conscientious about what's really going
      on, i.e. packets which travel back to the feed across the split
      virtual interface of the relay are in fact encapsulated.  For
      this reason, I would classify the rmp approach as more general
      than using relays for the purposes of routing over
      unidirectional links.

    o However, I also see value in providing bidirectional link
      semantics on unidirectional links.  I feel some networks may
      encounter difficulties deploying the modified protocols, or
      there may be other "control" protocols out there we have not
      considered where bidirectional semantics prove useful.  It may
      also in some cases ease deployment of new protocols where
      unidirectional links were not considered.  While use of a relay
      constitutes a "hack" of sorts, it is an elegant hack.  I think it
      deserves treatment--as evidence of this, consider that at least
      three groups have arrived at it independently.  And I think the
      udlr wg is as good a place as any to hash it out.

  This brings me to a question.  Can we continue to work on both
  approaches at the risk of ultimately providing two viable solutions
  to the problem?  With some more work, we may discover one or both of
  them intractable, but I don't think we know enough yet to make that
  determination.

  Now if you can bear with me a bit longer, I have a few remaining
  comments which more directly address some of the issues brought out
  in Walid's message.

[On Fri, 4 Apr, Walid Dabbous writes:]
# 
# Tunneling vs routing protocol modification 
# Elements for discussion

[...]

# 
# 
# c) easy configuration (without scalability issues)
# 
# the RPM solution is auto-configurable. WIDE and Aerospace
# tunneling solutions propose a dynamic configuration to 
# address pb1 above. Aerospace solution is based on a solution
# inspired from ICMP router discovery. When a receiver detectes
# a feed it sets a tunnel (entry in table that will trigger 
# encapsulation). However, we need a mechanism to "inform"
# the routing protocol about the asymetric metric to use 
# for this tunnel (as cited before).
# 

  This mechanism will depend upon the routing implementation on the
  reciever.  As was discussed on the list, I think the best we can do
  is call more attention to it in the draft.

[...]

# e) Scalability
# 
# The problem is the same for both approaches. 
# Tunneling solution may benefit from Mutlicast tunneling
# (e.g. a receiver establishing a multicast tunnel with all
# feeds, encapsulating routing information in multicast datagrams).
# Can someone provide more information on that?

  The big scalability problems arise in the face of large numbers
  geographically distributed receivers.  This constitutes a network
  architecture not commonly seen in internets, leading to implosion of
  state on the feed side.  One solution to this problem involves
  increasing the number of feeds to share the responsibility of dealing
  with all the receivers.  I think there are a number of ways to
  accomplish this in a relay-based solution.

  As you've described, multiple feeds can receive the same encapsulated
  returning packets if a common multicast address is used as the relay
  endpoint.  This should work as long as the encapsulation protocols
  is "stateless" and supports class D addresses.  If the encapsulation
  protocol is not "stateless", you will have a much bigger scalability
  problem on your hands anyway due to a state implosion at the relay
  endpoints.

  Another option is to send multiple packets with duplicated payload
  to different relay endpoints.  You could argue this is less
  efficient the above, especially for large numbers of geographically
  dispersed feeds, but this way you don't need multicast all the way
  back to the endpoints.

  Finally, you could divide up the physical forward medium into a
  number of subnets, each with a different corresponding relay
  endpoint.  Receivers would only encapsulate data bound for a
  particular subnet to its corresponding endpoint, but they could
  maintain multiple split virtual interfaces on different subnets, and
  therefore multiple relays.

  Or you might use any combination of the above.  The vipre draft
  attempts to incorporate the potential existence of all of the above
  scenarios, i.e., class D relay endpoints and stateless encapsulation
  as well as multiple split virtual interfaces and multiple relays for
  each interface.

thanks for listening and to those at the 38th, enjoy the home of
Graceland,

james

-- 
James Stepanek <stepanek@aero.org>   310/336-7911