Subject: RE: tspec table

From: Arun Viswanathan <[email-masked]>
Date: Tue, 28 Mar 2000 09:19:51 -0800

Juha,

> in the lsr mib, tspec table only supports intserv style traffic
> parameters and thus sort of assumes that the lsp was set up 
> using rsvp.
> cr-ldp has another set of traffic parameters.  shall we add another
> optional table, e.g., mlpsTrafficTable, that includes cr-ldp traffic
> parameters or how do you want to handle this?
> 

While defining the LSR MIB, one of the primary objective
was to keep it protocol agnostic. However, QoS being an
inherent property of an LSR (or for that matter an LSP)
we choose a generally acceptable way of defining QoS, that is,
using token bucket. But if try to extend that to support
various other QoS specifications, then we may not find an end
to this. Sometime back we raised this issue. It would be nice if
we had another MIB that modeled QoS and admission control
on a router/LSR, and we could simply point to the table and
be done with. Unfortunately nothing like that exists, besides
we didn't measure any interest in the WG on the issue of having a
common QoS resources MIB.

Hence the simple token bucket approach. I believe trying to
expand the scope of the TSpec table to satisfy various
QoS specifications is an undertaking in itself and outside the
scope of this document IMHO, but if it were available we would
have surely used it.

> -- juha
> 
> ps. why is the mib called lsr rather than mlps node mib, 
> since i haven't
> found in it anything that releates to forwarding of layer 3 packets?
> 
> 

Considering that an MPLS node will run one or more of the MPLS
protocols and one or more of the L3 routing protocols, will be
"capable of forwarding native L3 packets".

However, we will add some text in the introduction section
to stay clear of any ambiguity.

-arun