The IP Over NBMA (ION) Archive

Cell Relay Retreat>ION Archive>month:1996-Aug> msg00030



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

WG Last Call: draft-ietf-rolc-nhrp-09.txt

  • From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
  • Date: Fri, 9 Aug 96 23:20:21 JST
  • Cc: mohta@necom830.hpcl.titech.ac.jp, gja@bellcore.com, ion@nexen.com

> I've tried to help you see the difference between "NHRP the
> control plane mechanism", and "Consequence of using NHRP" (aka
> cut-through/ short-cut routes). I have concerns about the impact of 
> NHRP when deployed, but only because of potential for VC implosion in 
> the data plane.

Do you mean that a single egress/ingress router can't have
so much VCs?

Hmmmm.

But, as the degree of cut-through is controlable, it might be
possible to not to cut-through so much when # of VCs overflow.

Hmmmm.

But... as loop problems disallows to have medium length
cut-through, our control is now on whether hop-by-hop
or directly to the egress router. No 3hops-by-3hops
approach is available.

So, it seems to me that, with large enough scale, NHRP
cloud is just as inefficient as LIS cloud. That is,
hop-by-hop-by-*-by-hop-by-last5hop.

Or, do I misunderstand somethine on loop problem of
unicast cut-through?

> The ION WG's role now is to ensure the first version
> that makes it to Proposed Standard is implementable, not perfectly
> safe to use.

The following is not explicitely documented but seemingly a
obvious requirement for proposed standard.

That is, if it is proven in advance that the current approach can
not reach the draft standard status, it is a valid reason not to
make it proposed standard.

						Masataka Ohta