The MPLS WG Archive

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

Dave,

I have updated the TE link MIB according to your comments and comments from
Bert sent on Janaury 29, 2004 on MPLS mailing list. I have submitted the new
version, draft-ietf-mpls-telink-mib-06.txt, to IETF Web site.

Here is a summary of changes:

To address your concerns:
- I have added an Applicability of ifRcvAddressTable section.

To address Bert's comments:
- I have changed all TE-LINK-MIB references to TE-LINK-STD-MIB.
- I have changed the TeLinkBandwidth textual convention to be an OCTET
STRING (SIZE(4)). I have removed the DISPLAY-HINT clause. I have replaced
reference to 32 bit with 4 octet IEEE floating.
- I have added justification for use of 0 and 1 for
TeLinkSdhSonetIndication.
- I have updated the author list for the [LMP] and [GMPLS-ARCH] references.

Some more comments on your message:
- I have not added any text regarding special conditions of the media
concerning the inclusion of framing characters regarding ifXXXOctets
counters because there aren't any specific to TE link interfaces. As
specified in last paragraph of Section 8.1, the values of the ifXXXOctets
fields are the aggregation of the values of ifXXXOctets of all interfaces
that are contained by a TE link.

- ifRcvAddressTable is not applicable to TE link MIB because TE link
interfaces are logical interfaces. They are not associated with any
individual physical interface. As such they do not have media level
addresses and ifRcvAddressTable is not applicable to them. I have added text
to this effect in Section 8.

- Regarding application of the IP Tunnel MIB to TE links, as I have stated
in my December 3, 2003 answer to you (Cc'ed on MPLS mailing list), the TE
link MIB considers IP tunnels the same as any other underlying interfaces.
The interface stacking puts TE link interface on top of IP tunnel interface,
not at the same level as you describe below. This prevents the creation of
special cases for specific interface types and keeps TE links conceptually
the same for all interfaces.

Martin

----- Original Message -----
From: "Dave Thaler" <dthaler@windows.microsoft.com>
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
Cc: <dubuc.consulting@rogers.com>; <tnadeau@cisco.com>
Sent: Thursday, January 29, 2004 6:28 PM
Subject: RE: DT's review of draft-ietf-mpls-telink-mib-05.txt


(Also including Martin and Thomas)

I've checked draft-ietf-mpls-telink-mib-05.txt
to see what changes were made...

> > > -----Original Message-----
> > > From: Dave Thaler [mailto:dthaler@windows.microsoft.com]
> > > Sent: donderdag 27 november 2003 2:20
> > > To: Mpls (E-mail)
> > > Cc: Bert Wijnen
> > > 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.

Authors added:
        If ipAddrTable is implemented, this object must have the
        same value as the ipAdEntAddr object that belongs to the
        row in ipAddrTable where ipAdEntIfIndex is equal to
        ifIndex."

I am happy with that text.

> > > 2) teLinkIncomingIfId should have
> > >         SYNTAX Integer32 (0..2147483647)
> > >    instead of
> > >         SYNTAX InterfaceIndexOrZero
> > >
> > >     On Oct. 6, 2003, Martin wrote:
> > >     > I can make this change.

Yep, this was done as requested and now looks fine.

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

Authors changed the second sentence to:
If the
      link is numbered, the value of this object is 0 and the
      address is stored in the teLinkRemoteIpAddr instead."

I am happy with this wording.

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

I see no change in this regard.

My reading of 2863 is that the ifXxxOctets objects don't _require_
Any special text in this regard unless there are such "special
conditions".  So the draft is not necessarily wrong in any way here
(although it would be nice if the authors confirmed in email that
there are no such conditions).

However my reading of 2863 (text quoted above) is that some mention
MUST be made about ifRcvAddressTable, and in this regard the draft
still does not meet the IETF requirements for defining a new media
type as defined in 2863.  Fixing this is as simple as adding on
the order of two sentences, and in my opinion could be done after
IETF Last Call as part of acting on any feedback from there.

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

No change was made on this point either.  As mentioned in the last
paragraph immediately above, while I would have liked it to have been
in this draft, this is not a showstopper.  Clarification could be done
in a future revision.

-Dave