The Routing Over Large Clouds Mailing List Archive by date

[Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>]

> > > > But, as ATM large clouds do not and, in short-term, will not, exist,
> > > > NHRP is not a short- or long- term answer.
> > > 
> > > I don't believe this is true for all values of 'large' and 'short-term'. 
> > > In Scotland we have 4 Academic MANs based on ATM or mixed ATM/FDDI
> > > technology.
> > 
> > If your network is really a large cloud, that is, not necessarily
> > geographically large, but contains a large number of non-IP switches,
> > then, that is a bad news. It will be an administrative nightmare.
> 
> Of the order of a couple of dozen ATM switches across the 4 MANs;
> similar numbers of IP routers each with a single ATM interface -
> routers-on-sticks like I said. 

Thank you. I don't think it a large cloud.

Yes, the issue is debatable. But, for the purpose of this thread on
short-term answers, it's enough to say that anything which can be
supported by ATMARP or LANE do not need NHRP. It should also be
noted that, at the last IETF ROLC meeting, it was discussed that
at least thousands of hosts can be supported by ATMARP with
server synchronization.

BTW, I am a member of On-Line-University project in Japan, which
also have more than 20 switches distributed nationwide.

> Routers on sticks - we can't afford to install physically multihomed IP
> routers in parallel with ATM switches.

It seems to me that you have a phisically single homed IP routers
in parallel with ATM switches.

> > Isn't it obvious that cell-switching IP routers, whose cell switching
> > fabrics are setup by RSVP to have VCs for each flow, are just as fast
> > as legacy ATM switches?
> 
> Of course <wry smile> but such devices are not readily and affordably
> available in the UK.  Yet.

You can.

We have constructed a CSR by combining a physically single homed
IP workstation in parallel with ATM switches.

> What I wrote was "...each time I read one of the NHRP drafts I keep
> thinking there MUST be a better way.  Cell switching routers clearly
> aren't that in the short term...".  If I want to build a large-ish
> IP-over-ATM network with kit I could spec and order 3-6 months ago and
> install today CSRs are not the better way than NHRP.  If we were buying
> in a year's time they might be.  We need native ATM too to pure IP
> routers with ATM i/fs as the network nodes is not an option. 

I think you should contact Ipsilon or Toshiba.

> > It is true that RSVP spec may not fix in the short term, in which
> > case, we can use ST2 or draft RSVP, can't we?
> 
> Just as the whole world is not ATM it is also not IP.  

So? Why can you send IP over ATM even if the VC is signalled
by Q.2931?

Once cell switches are setup end-to-end by Q.2931, RSVP or ST2,
you can send anything including IP, AppleTalk, MPEG2-TS or
even AAL1. Intermediate switches, including CSRs, don't bother
to check the data content.

If you want to do it a little more formally, add a new filter
spec to RSVP.

> > > and aren't currently the IETF consensus about the way
> > > to go.
> > 
> > What consensus, do you think, we need?
> 
> How about the ION chairs or Joel saying "it's clear that the NHRP effort
> is a waste of time - let's drop it".   :-)

IMHO, it's enough to let the ION chairs or Joel say "NHRP is proven to
not to scale".

> > When we discussed on the issue of WG creation, Joel Halpern, the
> > IESG routing Area Director, stated that we can't create a WG only
> > to develop a router that needs no protocol.
> 
> I can't answer that,

You don't have to. It has passed Joel test.

> but I might ask why the IP over ATM WG didn't
> specify CSRs as the way to do tha job.

IP over ATM WG?

The conventional model of IP over ATM is the architecture to connect
ATM subnets. CSRs are located on the edges of ATM subnets and
connect them.

Inside subnets, CSRs do need some link local protocol such as ATMARP or
LANE.

Though I don't know why the IP over ATM WG didn't specify LANE as
the way to do tha job, it's not a problem of CSRs.

> > Anyway, to abandon NHRP, we only need a consensus that it is
> > proven to not to work.
> 
> Exactly - I don't see such a consensus in the IP-over-ATM-related areas
> of the IETF - do you?

Yes, at the last ROLC meeting, the proof was presented and
several attempts of counter proof, even by Joel, have failed.

How can you say there is no consensus?

						Masataka Ohta