The Routing Over Large Clouds Mailing List Archive by date

[rcallon@BayNetworks.com (Ross Callon)]

> This is getting to be a very confusing thread! Or is it just me?
> 
> Why would you need NHRP if you have I-PNNI? I must be missing something.
> 
> Bert

The short answer is that you need NHRP if you don't know the answer
already. I-PNNI allows you to know the answer a priori in some cases,
but not in all cases. Joel summarized it quite well [even if he 
continues to mispell "hierarchy" ;-) ]:

> Even if you have I-PNNI, there are at least four reasons you need
> NHRP:
> 
> 1) Router-Host and Host-Router communication
> 2) Heirarchy.  In the presence of Heirarchy, we will abstract out the
>     ATM addresses of the lower level routers
> 3) Virtual routers - the correct ATM destination for the traffic may not
>    actually be the router
> 4) Other routing protocols.  Even if some of your routers run I-PNNI,
>     you want interoperability with other protocols (including OSPF and BGP.)
> 
> Also, even if the whole network is using BGP with the "Next-Hop" attribute,
> the same kinds of issues apply.
> 
> Neither PAR nor full I-PNNI get rid of NHRP.  These are complementary
> technologies.
> 
> Thank you,
> Joel

Ignoring the case of multiple different routing domains which 
interact, there are multiple cases here. Even with PNNI Augmented 
Routing or Integrated PNNI, NHRP will be needed in some (but not
all) cases: 

1. Host to Router

Yes, I agree with several folks that PNNI Augmented Routing does 
not change the way that hosts work. Thus an ATM-attached host will
still use NHRP, and routers will respond appropriately. If you 
think of my criteria "use NHRP if you don't know the answer a 
priori", and assume that hosts don't run routing protocols, then
it is pretty clear that there will be lots of cases that ATM-
attached hosts need to use NHRP. 

2. Router to Router to Host

A similar thing happens at the other end, when you are doing 
router to router to destination host. Consider a corporate network 
which is using virtual networks (possibly based on LANE). There may 
be multiple ATM-attached hosts which according to their IP addresses 
are on the same subnet with "adjacent" IP addresses, but which are 
physically widely distributed on a corporate ATM network with widely 
differing ATM addresses. In this case either we need to announce host 
routes into the IP routing protocol, or we need something which knows 
how to find the hosts to advertise reachability to the appropriate 
subnet, with the understanding that we will end up with two hops 
across the ATM cloud unless we do NHRP (which starts at a router and
goes to another router, on the way to the destination host).  

3. Router to Router in a small ISP

For an Internet Service Provider whose network was small enough 
to be able to avoid hierarchical routing, then using either PNNI
Augmented Routing or Integrated PNNI would allow the provider to 
do away with router to router NHRP, and to have the necessary 
SVCs for data forwarding set up a priori (which is a win for
both latency and buffering reasons). 

4. Router to Router in a Large ISP

Things are a bit less clear in the case of an internet service 
provider which has a very large network, large enough to require 
hierarchy. Probably here we could make a distinction between a
"huge" ISP with a "huge" ATM subnet, versus a provider which is
barely large enough to require hierarchy. 

Consider a large ISP with 1,000 routers, each of which has multiple
interfaces to customers. Suppose that the routers are interconnected
via an ATM cloud. It is somewhat questionable to me whether you 
would want to have full n-squared SVCs set up a priori between all 
1,000 routers (each router would need 999 SVCs, and the total net
would need 499,500 SVCs). 

I could imagine this working with the network split into multiple
areas, with each router knowing the topology in its own area, but
only summarized topology in other areas. This would imply that the
router does not necessarily know enough to know the ATM exit point
for every other router, or to know precisely which router within
some other area is to be used to reach any one particular IP 
address. If this is the case, then NHRP could again be used to 
locate the ATM exit point for remote routers.

Now, one could imagine some optimizations which might eliminate 
the need for NHRP in some cases even in a hierarchy. To a large
extent this is a tradeoff between the amount of information
sent around in the routing protocol versus the need for queries.
For example, the summary for an area could include a list of ATM
addresses (of routers) plus the IP address prefixes that are 
reachable via each ATM address. This would be a lot more information
to advertise into the higher level of the routing protocol when 
compared with the address of an NHRP server, but would save on 
queries. I would expect that the default protocol behavior would 
be to just advertise the NHRP server and require queries, but
the protocol should allow the other option. For "slightly large"
ISPs the full list could save on queries, for very large ISPs we
might need the "less information but more queries" solution.

Actually, to be honest the thought of 1,000 or more routers all
connected over the same ATM cloud seems a bit scary regardless of
the routing solution. We had better have some locality of traffic
or we are in trouble. If traffic is really fully spread out and 
we really need 499,500 SVCs between the routers then we might be
doing something wrong. On the other hand, if 99% of the traffic 
is either to or from 5% of the sites, then perhaps we would need
only 50 SVCs from each router, or 50,000 SVCs in total (and we
could let the remaining 1% of the traffic take multiple hops 
across the ATM subnet). This seems more reasonable. 

5. Large Corporate Network

This would probably look like a combination of the above cases. 

Ross