The IP Over NBMA (ION) Archive

Cell Relay Retreat>ION Archive>month:1996-Jun> msg00171



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

draft-ietf-ion-ipv6atm-framework-00.txt

  • From: "Markus Jork" <jork@kar.dec.com>
  • Date: Fri, 21 Jun 96 19:37:35 +0200
  • Cc: ion@nexen.com, jork@nestvx.kar.dec.com
  • X-Mts: smtp

Joel,

thanks for your prompt feedback.

> 1) With regard to Neighbor Solicitiation/Reply, we seem to have two
>    reasonable choices.  
>    A) On the one hand, we can have IPv6 hosts emit NS messages for all 
>       destinations.  For those destinations outside of the logical link,
>       some appropriate router would transform (gateway) these into NHRP
>       requests.  (There would be similar transformations on the destination
>       side, and again when the NHRP response is received.)  This can be 
>       made to work.  It has the advantage of preserving precisely the
>       ND protocol.  It has the disadvantage of requiring protocol gatewaying.
>    B) Alternatively, we could require IPv6 hosts to emit NHRP requests.
>    It should be noted in evaluating these alternatives that my reading of
>    the Neighbor discovery document is that it is very explicit that we 
>    must provide the ND services, but that over an NBMA we are explicitly
>    NOT required to provide the exact same protocol.

I think you are missing a third alternative that Grenville is proposing
in his draft (draft-armitage-ion-tn-00.txt). The egress router from a
logical link could initiate a NHRP query when appropriate and send a
redirect to the source. No protocol gatewaying is required and the ND
protocol is precisely preserved.

> 2) With regard to the LLS for purposes other than neighbor solicitation,
>    it seems to me that the LLS in attempting to be "simpler" than MARS,
>    is functionally equivalent to a coresident MARS/MCS.  I would ask
>    why we want to develop two mechanisms, including two replication
>    protocols and two client behaviors, in order to support two very similar
>    aspects of the same problem?

This is certainly a valid question. An LLS is some kind of "coresident MARS/
MCS functional equivalent" with some extra features. Our draft describes
how MARS and LLS would happily co-exist and jointly provide an all-purpose
multicast service for the logical link. We felt this was the best aproach.
But if we find ways to melt things together even more: that's probably a
good thing.

Markus