The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Aug> msg00144



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

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

  • From: "Thomas D. Nadeau" <tnadeau@cisco.com>
  • Date: Fri, 30 Aug 2002 17:33:26 -0400
  • Cc: "mpls@UU.NET" <mpls@UU.NET>

At 03:58 PM 8/29/2002 -0700, Yuan Gu wrote:
>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?

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

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

         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.
>
>Regards!
>Yuan



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