The MPLS WG Archive

["Thomas D. Nadeau" <tnadeau@cisco.com>]

At 02:48 PM 8/30/2002 -0700, Yuan Gu wrote:
> > >If yes, mean while
> > >this table allows creating new tunnel, updating and remove existing
> > >tunnel. Is that to say a tunnel can be updated or removed from
> > >transit/egress node (even created)?
> >
> >          In general, no. Most implementations only allow modification
> > to a tunnel at its head. In general, the information shown at the 
> mid-points
> > and tail are informational only.
> >
> >
>
>Then how do you inform SNMP that for same table, some rows can be modified
>while some other rows can't( most of the objects in TunnelTable are
>"read-create")?

         The creation of particular rows in the table is always
governed by the agent, regardless of where the MIB is
running along the tunnel's path. If an implementation allows
read-write access to head-end entries while not allowing
them to others, this is fine but should be spelled out in
the agent capability statement for that implementation (assuming
that it is inline with the conformance statement in the MIB).
Since the MPLS-TE MIB defines most of its objects as read-create,
this means that by default, and agent allows write access
to them after they are created, but a variation on this can be
spelled out by the implementation to restrict write access either
altogether, or at mid-points or tails.

         --Tom


>Or you just send error message back to SNMP when you receive a
>SNMP "set" request but you don't want to change your value?






------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.