The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Jan> msg00044



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

suggested added text for multipath in draft-ietf-mpls-lsp-pin g-01

  • From: Curtis Villamizar <curtis@fictitious.org>
  • Date: Thu, 09 Jan 2003 14:59:44 -0500
  • cc: curtis@fictitious.org, "David Allan" <dallan@nortelnetworks.com>, neil.2.harrison@bt.com, mpls@UU.NET


In message <5.2.0.9.2.20030109134939.068c5178@bucket.cisco.com>, "Thomas D. Nad
eau" writes:
> >
> >In case you haven't guessed that ISP was ANS and the routers were the
> >NSS routers that were produced as part of the NSFNET project in the
> >early to mid-1990s.  I think we did manage to do similar queries on
> >Bay and Cisco routers using show commands with infinite line counts
> >(using TCP instead of SNMP to gather information).  Use what works!
> 
>          Again, I don't care which management interface you use as long
> as it works for you. I still personally don't think that querying/polling
> 100,000 or more entries frequently is a good idea -- via any interface.

The NSS did this the best.  A request for the routing table was
serviced in a single atomic write to application space.  BSD
copy-on-write VM semantics are nice to have.  From their it was
transferred further, like written out to the controlling terminal if
doing a netstat -k (netstat -r using the special kernel interface) or
processed or transferred by the application by whatever means.  Very
low overhead compared to the old successive get-next approach.  Bulk
SNMP trasfer could be done in the same way today.

> >MIB access does create some inefficiency.  Even with a better way to
> >access the counters, doing the processing in a nearby pizza box
> >creates a bit more inefficiency due to the need to move the data.
> >Neither is all that hard.
> >
> >Some boxes used to fall over if you do too much SNMP query.  I hope
> >that is no longer the case.  At least some can handle it.
> 
>          My assertion is that all boxes will eventually fall over given enoug
> h
> work to do. *)

Wrong!  Not with SNMP if there are hardware queues that give SNMP a
WFQ queue and are only serviced if the router can handle it.  Abusive
query, including intentional query at near line rate cannot knock over
a router designed that way.  SNMP queries will be dropped though.

>          --Tom

Curtis

ps - we're off topic now.