Re: Difference between INRIA and WIDE idea

[Yongguang Zhang <ygz@isl.hrl.hac.com>]

At 07:52 PM 11/26/97 +0900, IZUMIYAMA Hidetaka wrote:
>Dear all,
>
>I summarize the major difference between INRIA and WIDE
>for discussion of UDLR mailing list.
>
>         %%%            %%%%
>
>1.The tunnel among the feeds
>
>  INRIA wrote nothing about the tunnel among feeds.
>
>  I think that the feeds must set up the
>  tunnel each other as mesh topology to exchange the
>  information for routing protocol.
>
>  (ex.1 OSPF)
>  One of feeds will be a DR of a UDL.
>  To do this, feeds must exchange the OSPF
>  message(ex. HELLO message,etc.) each other.
>
>  (ex.2 DVMRP)
>  One of feeds will be a DR of a UDL.
>  To do this, feeds must exchange the DVMRP
>  message(ex. PROBE messages,etc.).


I agree that we should provide a mechanism for feeds to communicate with
each other.  Instead of a mesh of tunnels, I suggest an "all-feeds" 
multicast (AFM) group.  Since we assume that UDL feeds cannot receive
(see I-D), the feeds must depend on AFM to send/receive multicast/broadcast
on the UDL subnet.  Each feed should join an Internet multicast group
pre-assigned for AFM.  (If UDL feeds can indeed receive, AFM will be a 
local multicast in the UDL.)


>2.The tunnel from receiver to feeds
>
>  In section 5.3.4. of INRIA's I-D,
>  a Receiver maintains the all active feeds' list and
>  select one feeds'.
>
>  I think a receiver doesn't need to maintain the
>  list of all active feeds. Normally a receiver sets up 
>  a the tunnel to one of feeds.


INRIA's I-D maintains a list of all active feeds because
it relies on the list to send a message to "all-feeds".
If we have AFM (as described above), we may not need to
keep the list.

Another usage of the list is for efficient implementation
of "any-feed" semantics (for example, if a receiver wishes
to send a message to all receivers, it can tunnel to "any-feed").
But before we have "anycast", we may want to either keep the
list and pick one randomly each time, or pick one permanently
(if you know the distance of all active feeds, it will
be good to pick one closest).  Maybe keeping the list is a
good idea.



>3.Function of DTCP(Dynamic Tunnel Configuration
>  Protocols)
>
>  In the I-D of INRIA, describe the Dynamic Tunnel Configuration
>  (DTC). According to this section, INRIA's feeds doesn't keep 
>  the information of receiver state.
>
>  Our DTCP control the state of receiver at feed and
>  can do dynamic IP address allocation for receiver if necessary.


We have DTCP, HELLO (INRIA's I-D), and TEP.  We can argue about
that in the meeting...


>4.Requirement for on-demand ARP


Should we not include the APR issue in UDLR?  In my opinion the
ARP mechanism in UDL is simple as long as the receiver tunnels the
ARP-reply back in GRE.  That can be one-sentence in the I-D as a
requirement for UDL receivers.

The on-demand/caching/refreshing ARP issue is interesting but it is
mainly caused by long delays.  If I have UDL wireless modem that gives
me a 10ms round-trip time, I can still use ARP.  But even if I have
a BI-directional satellite link I would definitely want to have some
sort of ARP caching/refreshing to cut the ARP latency (or call it
ARP-prefetching).

So is it fair to say that caching/refreshing ARP is a mere latency
issue?  I hope we can avoid any latency but non-UDL issue here,
although two are often blended in satellite links.


>5.Requirement of tunneling
>
>    If the requirement of the tunneling mechanism for udlr
>    is just carrying IP datagrams, this system can employ
>    any tunneling mechanism which can carry IP datagram
>    (eg. IPonIP, GRE, etc.).


Did we have a rough consensus on last IETF about using GRE?


>-- izu --
>


Yongguang Zhang