Subject: support mpls-te-mib in transit and tail points.

From: Yuan Gu <[email-masked]>
Date: Thu, 29 Aug 2002 15:58:09 -0700

Hi:

In mpls-te-mib mplsTunnelTable, the object mplsTunnelRole has three
values -- head, transit and tail. Does that mean beside ingress node, TE
mib can also be supported in transit and egress node? 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)? And one more thing is in the transit
case, how do you provide some TE parameters such as
mplsTunnelPrimaryInstance because transit node might not know it?

Thanks for your clearify.

Regards!
Yuan

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 29 Aug 2002 19:18:14 -0400

Hi,
You can certainly implement the TE MIB at transit nodes.
It makes very good sense for reading about tunnels that transit an LSR.
It might make sense in some implementations to allow deletion of tunnels from
non-ingress nodes.
It makes no sense for attempting to create tunnels from non-ingress nodes (in
today's signaling protocols).

You are correct that some parameters shown at the ingress are not signaled and
so cannot be known at non-ingress nodes. On the whole, these parameters are
concerned with selecting which of a set of tunnels configured at the ingress
should be signaled, so it follows that at non-ingress nodes you only know about
those that were actually signaled.

Regards,
Adrian

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 30 Aug 2002 17:33:26 -0400

At 03:58 PM 8/29/2002 -0700, Yuan Gu wrote:
>mib can also be supported in transit and egress node?

         Yes, the intent was for implementations to support the MIB
(at least the parts that make sense) at mid-points and tails. Also letting
the NMS about which hop type (mid/head/tail) an LSR contains is
useful for a variety of management tasks.

>If yes, mean while
>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.

>And one more thing is in the transit

         Some objects do not make sense to show at mid-points/tails
(i.e.: the tunnelHead instance -- generally instance=0).  We are
trying to clarify when it makes sense to support certain objects
and when it does not at mid-points/tails/heads in the DESCRIPTION
clauses in the updated MPLS-TE MIB that is being edited
along with MIB Doctor comments now (really, ask Arun :) ).

         --Tom

>Thanks for your clearify.

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

---

From: Yuan Gu <[email-masked]>
Date: Fri, 30 Aug 2002 14:48:20 -0700

> 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")? 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?

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 30 Aug 2002 17:56:11 -0400

At 02:48 PM 8/30/2002 -0700, Yuan Gu wrote:
>"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