The IP Over NBMA (ION) Archive

["M.J. Robinson" <92mjr1@eng.cam.ac.uk>]

Hi Folks,

	Unfortunately I'm not able to make it to the Montreal meeting.
However, there are a few points that I would like to raise regarding NHRP,
so this email is intended to draw attention to these. Thanks go to Adrian
Smith (BT) for reviewing this email and contributing to the deployment
scenarios section. 

	Matthew.

R2R NHRP.
--------
o Very little work seems to have been done so far
o Possible that R2R NHRP will be deployed first (to support legacy
equipment), then v1 NHRP used as ATM becomes available right between desktops
o Provision for QoS desirable, but perhaps not going to be much used at first ?

Deployment Scenarios.
-------------------- 
I'd like R2R NHRP to work in the case of "legacy" router networks attached
to single large cloud - i.e. frame relay (SVCs) and SMDS as well as ATM! 
In which case I could invisage large corporate networks with the following
characteristics
o large sites (e.g. SNA house's host sites) with multiple router
connections to cloud network
o requirement for large number of cut through routes to these large sites
o rapid re-routing around failure of one of these large site
accesses/routers
(clear down all cut throughs and re-establish to alternate site access.)
(comparible to OSPF reconvergence with short dead timers)
o sensible management of prefix based cache entries is essential due to
large numbers of hosts reachable via each NHRP edge router. 

Domino Effect.
-------------
o Definitely needs to be dealt with in implementations
o Draft v8 removed unworkable solutions (good)
o Draft still doesn't mention use of multiple NHRP network ID's

Holdtime Expiration Behaviour.
-----------------------------
o Potential for cut-through to oscillate (torn down, then re-established)
when holdtime expires
o Best to define consistent behaviour, especially if short holdtimes are to
be used
o Some possibilities are:
	- Re-Request for actively used destinations before holdtime expires (my
prefered solution)
	- Allow entries to be used for a _short_ while after holdtime expires,
pending Reply
o NHS's replying with non authoritative responses should decrement the
hold time advertised so that it is only the remaining time from the
original request/reply

Ensuring Cache Entries Remain Valid.
-----------------------------------
o Major part of R2R NHRP
o Keepalives my prefered scheme (definitely detect failure)
o Should keepalives be optional ? (Turn off if other mechanisms - eg Link
Layer indications - usable)
o Request/Response scheme (cf Ping) or "Spontaneous Emission" (less
controlled) ?
o How to handle multiple shortcuts between a given Requester and Responder:
	- how likely is this case ?
	- options include:
		- keepalive per shortcut
		- keepalive Response includes list of all valid shortcuts
		- send purges for shortcuts which become invalid

o "Router Feedback" could be added as an optimisation to indicate "better"
shortcuts
	- perhaps define "re-request advised" packet (and ensure all
implemenations accept this). Then implementers can add this as a
refinement if they wish ? 

Unreachable Destination Behaviour.
---------------------------------
o If data isn't sent via routed path, won't get an ICMP Dest. 
Unreachable. Hence need to deal with this case in NHRP (also more general 
soln.)
o Should holdtime for a NAK be less than that of a normal reply ?
o Should provision be made for "Router Feedback" to be added as an 
optimisation ?

Triggering NHRP Requests.
------------------------
o Triggering criterea important part of NHRP use
o Could use ISDN style system - i.e. cut-through on demand

OSPF Extensions.
---------------
o An alternative way to advertise ceratin shortcuts. Needs more thought as
to consequences of using this scheme.
o Might be able to advertise each shortcut to central services (such as
Network 3 in Fig.1 of my conference-style paper) (only suitable if a small
number of such redundant accesses)
o Curtis noted that NHRP leads to a Request implosion at an egress router.
Such a router will probably be advertising external route(s) and so might
also advertise itself as a shortcut destination. 

NHRP Un-Request.
---------------
o Just an idea at present - needs further thought
o Allow requester to send an "Un-Request", indicating that the shortcut is
no longer needed and so all state relating to it can be discarded

(The End)