The IP Over NBMA (ION) Archive

[shur@arch4.ho.att.com]

Grenville,

> From faline.bellcore.com!gja@caig1.att.att.com  Tue Jul  9 10:51:24 1996
> David,
> 	[..]
> >>The argument/debate seems to be:
> >>
> >>1) There exist some problems (e.g. IP multicast over a large ATM cloud
> >>where the size of the multicast groups is very large), where
> >>straightforward use of NHRP causes an excessive amount of signaling
> >>messages to be processed/generated by senders to that group. Some people
> >>have concluded from this that NHRP is not useful.
> 
> Please - to encourage clarity of people's understanding of the issues
> here I'd like to see an end to this bogus association of NHRP with
> multicast (cut-through or otherwise). It lacks the facilities to manage
> pt-mpt SVC forwarding pathes after their establishment. Tracking unicast
> link layer destinations and multicast link layer groups are almost
> orthogonal problem spaces. (i.e. there is no 'straightforward use of
> NHRP' that has been analyzed in this thread.)

In the interest of correctness:

>From Yakov's (Sparse mode PIM over ATM) draft abstract: 
"In this document we describe how a combination of NHRP and the sparse
mode PIM could be used to establish shortcuts (single IP hop) for
the multicast traffic traversing an ATM network." 

I have read this document and don't find anything "bogus" about 
its association of NHRP and IP multicast.

> 
> >>2) Another view is that there exist a number of problems (e.g., unicast
> >>cut-through, IP multicast over small multicast groups per above draft)
> >>where NHRP provides useful solutions. Other people have concluded from this
> >>that NHRP is useful.
> 
> Yakov's draft (such as I remember of it) was not to do with small mc
> groups per se, but the interconnection of mrouters attached to the edges
> of a transit ATM/NBMA cloud. It demonstrates an interesting application
> of NHRP (but is a solution to a problem that can be solved in other
> ways).

You may be confusing Yakov's work on Sparse Mode PIM (which is what I have been
referring to) and his draft on R2R NHRP.

> 
> NHRP addresses a palpable need people have to dynamically bypass
> topological mismatches between IP unicast paths and underlying
> ATM paths. That is all. (It is only of secondary importance that
> you reduce the number of reassembly/segmentation hops.) In so far
> as it achieves this need, it is a good thing. However, it is
> also worth remembering that if you minimise your topological
> mismatch, you reduce the need for unicast cut-throughs (regardless
> of the name of the protocol you use to discover them).
> 
> The issue for multicast cut-throughs is not whether you can conjecture
> a use for them, but whether it is worth the effort to construct and
> manage them.
 
Well, do you think its worth the effort?

David.