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

From: "David Allan" <[email-masked]>
Date: Thu, 9 Jan 2003 09:53:26 -0500

Hi Curtis:

I gathered the intent, I'm just seeking to align MPIndex with some other
node administered value (such as TTSI or IFIndex) so we do not require
further changes to make the relevant stuff accessable via MIBs or CLI

Dave

> -----Original Message-----
> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Thursday, January 09, 2003 9:50 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: suggested added text for multipath in
> draft-ietf-mpls-lsp-pin g-01 
> 
> 
> 
> In message 
> <[email-masked]>, "Da
> vid Allan" writes:
> > 
> > 
> > Hi Curtis:
> > 
> > <snipped>
> > > 
> > > 
> > > Just currious.  Is the TTSI appropriate to handle 
> multipath, which is
> > > what we are talking about here?  At a midpoint there 
> would be multiple
> > > indices, each index representing one branch of the multipath at
> > > midpoint.
> > 
> > TTSI is an access point identifier, so it would work. Some 
> folks wanted to
> > avoid having to request signalling changes by suggesting 
> existing RSVP
> > fields COULD be used to populate TTSI at the egress (tunnel 
> ID) and this has
> > resulted in a lot of confusion as to whether TTSI 
> identified an access point
> > or a path. Each LSP ingress will have a unique TTSI.
> > 
> > > 
> > > In any case, TTSI should not be used because it created a 
> completely
> > > unnecessary tie to an ITU document.  Ifindex (and maybe 
> TTSI) would
> > > not be appropriate if the multipath split were in a 
> proprietary link
> > > bundle.
> > 
> > Only suggestion I would make is that MPIndex should then be 
> 32 bits, so that
> > folks that want to use the (albeit poorly named) LSP ID 
> part of TTSI could
> > do so (and this would not require an explicit tie to any 
> ITU documents). A
> > node administered access point identifier should be able to 
> work even for
> > propreitary bundles.
> > 
> > cheers
> > Dave
> 
> 
> The intent was that it was an index indicating the Nth branch of the
> multipath branch point.  N would typically ba a small integer and very
> seldom would have to even approach 100.
> 
> Curtis
> 
>

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 09 Jan 2003 10:03:55 -0500

In message <[email-masked]>, "Da
> further changes to make the relevant stuff accessable via MIBs or CLI

The counter that tells you how much can in for Label L and went out
Path N is different from the counter that tells you how much traffic
went out interface I.  So you can't reuse MIB values and get useful
counters.

For example - It you expect a 50:50 split, its nice to poll a MIB and
see that the result of the hash is at least close.  It would also
diagnose different problems.  You may see lots of traffic on the
outbound interface, but if you see one of these smaller counters stop
incrementing then you know you have a problem.

Curtis

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 09 Jan 2003 10:53:01 -0500

At 10:03 AM 1/9/2003 -0500, Curtis Villamizar wrote:

>In message 
><[email-masked]>, "Da
>vid Allan" writes:
> > Hi Curtis:
> >

         There are byte counters in the LSR MIB for example, that
will show you per-label traffic counters. So if you are load-sharing
at some node and sending out two or more labels, then you can
look at the bytes/packetsOut on those outSegments (in LSR MIB
terminology).

>incrementing then you know you have a problem.

         Yes, but this is a difficult strategy at best due to the (typically)
large TFIBs of most production LSRs.  This is akin to watching routes
in the IP routing database, which can be pretty big.  Scanning/polling
this DB to look for anomalous counters is difficult performance-wise.

         --Tom

> > > seldom would have to even approach 100.

"The difficult, we do immediately.  The impossible takes a little longer." 
-- Air Force Motto

http://www.mkp.com/books_catalog/catalog.asp?ISBN=1-55860-751-X

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 09 Jan 2003 13:08:27 -0500

In message <[email-masked]>, "Thomas D. Nad
> this DB to look for anomalous counters is difficult performance-wise.

The last ISP that I worked at that *did* do fine grained consistency
checking did not use a MIB at all.  They had a Unix based router and
could access the counters more efficiently and produce consistency
checks on the router itself.

That same provider also *did* capture the routing table on all of the
routers and check it for consistency across routers.  That also was
*not* done with SNMP.  I know they did because I did it.  OTOH those
queries were run regularly only when there were under 20,000 routes.
I think we resurected it and ran it when we identified the broken MED
processing initially defined for BGP.

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!

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.

Curtis

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 09 Jan 2003 13:56:06 -0500

>checks on the router itself.

         Whatever you feel is the best tool to use is fine with me.
In my experience, polling the TFIB for its counters hasn't been
a successful approach using any tool.  I was only pointing out
which MIB objects are available to get the values you were interested
in from your initial posting.  Of course, everyone has a CLI for those
counters too, but I think you were questioning whether such variables
exist in MIBs today.

>(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.

>that is no longer the case.  At least some can handle it.

         My assertion is that all boxes will eventually fall over given enough
work to do. *)

         --Tom

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 09 Jan 2003 14:59:44 -0500

In message <[email-masked]>, "Thomas D. Nad
> 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.

>          My assertion is that all boxes will eventually fall over given enoug

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.

Curtis

ps - we're off topic now.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 09 Jan 2003 15:41:27 -0500

> >          My assertion is that all boxes will eventually fall over given 
> enoug
> > h
> > work to do. *)
>

         I didn't specifically say _which_ work.  *)

         --Tom