The MPLS WG Archive

["Dave Thaler" <dthaler@windows.microsoft.com>]

Bert asked me to post the current status of the telink-mib discussion.
Since a new version hasn't been submitted since my initial review, I'll 
briefly summarize where I think we are on draft-04.

1) Relationship between teLinkLocalIpAddr and ipAddrTable needs to be
   clarified, and authors agreed.

   On Oct. 22, 2003, Martin Dubuc wrote:
   > I will add text in the DESCIRPTION clause to emphasize the 
   > relationship between teLinkLocalIpAddr and ipAddrTable.

2) teLinkIncomingIfId should have 
        SYNTAX Integer32 (0..2147483647)
   instead of
        SYNTAX InterfaceIndexOrZero

    On Oct. 6, 2003, Martin wrote:
    > I can make this change.

3) teLink{Outgoing,Incoming}IfId descriptions should be more clear:
           "If the link is unnumbered, the outgoing interface identifier
is
            set to the outgoing interface identifier chosen for the TE
link
            by the advertising LSR. For numbered links, the address is
            stored in the teLinkLocalIpAddr instead."
    It is unclear what is meant by "instead".  If the value here should 
    be 0, say that explicitly, as in:
           "If the link is unnumbered, the outgoing interface identifier
is
            set to the outgoing interface identifier chosen for the TE
link
            by the advertising LSR. If the link is numbered, the value
is
            0."

    On Oct. 6, 2003, Martin wrote:
    > I can be explicit as you suggest.

4) Requirements from section 4 of RFC 2863 not met yet in section 8 are:

   ifRcvAddressTable
      The media-specific MIB designer MUST specify the applicability of
      the ifRcvAddressTable.

   ifXxxOctets
      The definitions of ifInOctets and ifOutOctets (and similarly,
      ifHCInOctets and ifHCOutOctets) specify that their values include
      framing characters.  The media-specific MIB designer MUST specify
      any special conditions of the media concerning the inclusion of
      framing characters, especially with respect to frames with errors.

   I have seen no response from the authors yet on this point.

5) On the topic of extending the tunnel MIB, I believe everyone agreed 
   on the following points:

    a) Some objects are redundant with the IP Tunnel MIB (RFC 2667) in 
       the case where the MPLS TE link is a tunnel over IPv4.  These 
       redundant objects are useful when the agent does not support the 
       IP tunnel MIB, or when the tunnel is over IPv6, which is not yet 
       handled by 2667.

    b) Regardless of what happens with this MIB, RFC 2667 should be
updated
       to handle IPv6.  (This was done,
draft-thaler-inet-tunnel-mib-00.txt
       was posted to the ifmib and ipv6 lists, presented in the IPv6 WG
       in Minneapolis and was accepted as an IPv6 WG item since the
IFMIB
       WG is closed.)

    c) It would be good to be done with the MPLS TE link MIB now and
       not be blocked on any other document.

   To briefly change the subject to an analogous issue, Kireeti, Bert, 
   and I met at IETF to talk about a similar issue in the TEWG MIB.
   We concluded that the best answer was to allow the MIB to be used
   both for tunnels (where it can logically extend the tunnel MIB)
   as well as for non-tunnel objects, where it does not extend the
   tunnel MIB.  This can be done in such a way as to not change anything
   in the MIB definition itself, just the intro text in the document.
   
   I think this same solution can be used in the MPLS TElink MIB, and 
   hence solve the problems of not being able extend the tunnel MIB 
   when an agent supports it.

   Hence we could add a small subsection to section 8 along the lines
of:

    8.1 Application of the IP Tunnel MIB to TE Links
 
    The IP Tunnel MIB [RFC2667] defines managed objects for managing 
    tunnels over IP. For TE Link interfaces which correspond to tunnels 
    over IP, an agent supporting the IP Tunnel MIB would have entries in

    that MIB for TE tunnels. Interfaces in the IP Tunnel MIB use ifType
= 
    tunnel (131), and have a subtype identifying the actual
encapsulation 
    method.  Hence, in the case where MPLS is using a single TE tunnel 
    link, the interface stack might appear as (for example):
 
        +-----------------------------------+
        | MPLS interface ifType = mpls(166) |
        +-----------------------------------+
        | Tunnel link ifType = tunnel(131)  |
        +-----------------------------------+
        | Underlying Layer...               |
        | ifType = ethernetCsmacd(6)        |
        +-----------------------------------+

   [Note: I'm not sure whether the above stack is correct, since I'm
   not sure what data encapsulation is used on the wire.  The above
   stack would be correct if an actual data packet on the wire looked
like:

      Ethernet - Outer IPv4 - MPLS - Inner IPv4 - payload 

   If the packet looks different, the stack would be different.]

   Also update the DESCRIPTION clauses of teLinkEntry, 
   teLinkDescriptorEntry, teLinkSrlgEntry, teLinkBandwidthEntry
   which all say ifType must be 200, to say 200 or 131.

   This would allow the TE link mib to be used both ways, and hence
   allow the benefits of the tunnel MIB, without requiring it or any
   other changes to an existing implementation.

   The alternative would be to publish without this now and rev the 
   TE Link MIB at the same time as the Inet Tunnel MIB would go to RFC.

-Dave