Subject: MPLS-TE-MIB Report 2/3: General Questions and Comments

From: "Zhu, Rupert" <[email-masked]>
Date: Mon, 11 Nov 2002 16:26:53 -0600

------------------------------------------------------
MPLS-TE-MIB Report 2/3: General Questions and Comments

This Email contains some general questions.  Next Email contains
specific questions and comments.

TOPIC 1: Regarding "mplsTunnelRole".

   A tunnel instance may take one of three possible roles: Head, Transit,
   Tail.  Among the 37 fields in mplsTunnelTable, some are not applicable
   to every role.  For example, the fields

        mplsTunnelIsIf
        mplsTunnelIfIndex

   are not applicable at Transit nodes.

   In analogy to ATM SPVC, I guess Head node should
   have the largest set of applicable fields.  Transit node is likely
   to have the smallest set of applicable fields.

Q1: In mplsTunnelTable, exactly which table fields are applicable
    to which roles? Could the authors make it clear?

Q2: For an LSP established through signaling, how can a transit node
    find out the mplsTunnelIndex?  The value of this field is always
    required because it is part of INDEX of the table.

Q3: When the tunnel instances of a (logical) tunnel are diversely routed
    through signaling, how can a transit node get the info of other
    tunnel instances that belong to the same tunnel?  It seems that
    the transit node can only record one tunnel instance if it is
    established through signaling.

TOPIC 2: In Relation to MPLS-FTN-MIB

    Excerpt from MPLS-FTN-MIB (v05)
    -----------------------------------------------------------
    mplsFTNActionPointer OBJECT-TYPE
       SYNTAX             RowPointer
       DESCRIPTION
            ........
            If mplsFTNActionType is redirectTunnel(3), then this
            object indicates the instance of mplsTunnelEntry for
            the MPLS TE tunnel to redirect matching packets to.
    -----------------------------------------------------------

Q1: Consider a scenario that a (logical) tunnel is composed of 5
    diversely routed tunnel instances (LSPs) that run in a load-sharing
    manner.  Which tunnel instance should be selected for this FTN
    mapping?  What's the criteria?

Q2: In the same scenario, if administrator delete one of the tunnel
    instances and that happens to be the one FTN mapped to, what would
    happen?  Orphan pointer?  Any succession rules?

In my opinion, the MIB definition quoted above is a kludge that
twisted the logical relationship and added undesirable complexities.
(E.g., Q1 and Q2 above.)

The correct design should have FTN mapped to the (logical) tunnel,
instead of a member tunnel instance.  This way, the member tunnel
instances may be added, removed or modified freely, without affecting
the FTN mapping.  And we wouldn't need to worry about selection
criteria, deletion procedure and succession rules.

Regards,

Rupert Zhu
System Engineering
Santera Systems Inc
3605 E. Plano Parkway
Plano, TX 75074
Phone: 972-461-6383

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 12 Nov 2002 10:14:06 -0500

Actually, it is possible that an implementation
might use an ifIndex for each tunnel instance. There
is certainly nothing to preclude this in any of the
standards.  So to be precise, I think that the BCP is
that these only apply to heads, but perhaps not always.

>     to which roles? Could the authors make it clear?

         Which objects do you think are not documented? We
did add text in some places to update this.

>     required because it is part of INDEX of the table.

         I don't understand this question. Just look at the tunnelTable.
If you want the heads, we recommend these use instanceIndex = 0,
but you can also look at the tunnel's role if that is not the case.

>     established through signaling.

         Two points. First, when is a TE tunnel not established through
signaling?  Second, I think you can just look at the table to
find the tunnel instances in the table.

>     Excerpt from MPLS-FTN-MIB (v05)

         The FTN MIB can use two models for FTN. First, a single tunnel
head pointed to by a single FTN entry. The tunnel head uses multiple
LSPs. The second mode allows for multiple FTN entries that point
at tunnel heads to represent the multiple paths.

>     happen?  Orphan pointer?  Any succession rules?

         I believe that the FTN MIB's tables have been updated to
be very clear what needs to happen in these cases. In essence,
the agent must take inappropriate rows out of service.

>criteria, deletion procedure and succession rules.

         This is certainly one way that you can use the FTN
MIB (as explained above).  However, we did not feel that
we should restrict the use to just this way.

         --Tom

>Phone: 972-461-6383

Success is relative; the more success, the more relatives. -Anonymous