The MPLS WG Archive

["Martin Dubuc" <m.dubuc@rogers.com>]

Dave,

I have studied your response in greater details.

I have an issue with the last part of point number 4. Your layering proposal
is not in line with the intent of the TE link MIB. TE links are really
logical entities used to present a set of one or more network resources with
a consistent set of characteristics. By allowing a TE link to be either a TE
link or a tunnel, we are breaking this paradigm. TE links would be in some
cases logical entities, and in other cases "physical" entities (or should I
say real network resources).

For consistency, I would like to see tunnels handled the same as other
technologies. In the example that you present, I would like to see the
layering as follows:

+-----------------------------------+
MPLS interface ifType = mpls(166)
+-----------------------------------+
TE link ifType = TE link(200)
+-----------------------------------+
Component link
Tunnel link ifType = tunnel(131)
+-----------------------------------+
ifType = ethernetCsmacd(6)
+-----------------------------------+

Martin

----- Original Message -----
From: "Dave Thaler" <dthaler@windows.microsoft.com>
To: "Mpls (E-mail)" <mpls@uu.net>
Cc: "Bert Wijnen" <bwijnen@lucent.com>
Sent: Wednesday, November 26, 2003 7:41 PM
Subject: RE: DT's review of draft-ietf-mpls-telink-mib-04.txt


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