Subject: WG last call on the FTN mib module and the TE mib module

From: Loa Andersson <[email-masked]>
Date: Wed, 25 Jun 2003 01:28:16 +0200

All,

this mail starts a working group last call on

       Multiprotocol Label Switching (MPLS) Traffic Engineering
                   Management Information Base

                 <draft-ietf-mpls-te-mib-10.txt>

This ID has just been sent to the Internet-Drafts for publication and
will show up shortly, in the mean time it will be found at:

http://urax.utfors.net/~loa/draft-ietf-mpls-te-mib-10.txt

This mail also the starts a working group last call on

        Multiprotocol Label Switching (MPLS) Forwarding Equivalence
          Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE)
                        Management Information Base

                      draft-ietf-mpls-ftn-mib-07.txt

for this mib module the wg last call is limited to the changes since the
previous version version

This ID has just been sent to the Internet-Drafts for publication and
will show up shortly, in the mean time it will be found at:

http://urax.utfors.net/~loa/draft-ietf-mpls-ftn-mib-07.txt

The last call will en June 29th 09.00 ET.

-- 
/Loa

mobile + 46 739 81 21 64
email: [email-masked]

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 26 Jun 2003 17:58:50 -0400

Hi,

I am working my way through draft-ietf-mpls-te-mib-10.txt and thought I would send comments as I find them, rather than allowing them to pile up.

Very many appologies that these comments come so late in the day. My excuse is that I last implemented this draft about three years ago. Much has changed but many of my gripes then have not been answered. I have not been focused on the review of this draft in the intervening years.

Adrian

1) Section 2.

   An explicitly routed LSP (ERLSP) is referred to as an MPLS
   tunnel.  It consists of one in-segment and/or one out-
<  segment at the ingress/egress LSRs, each segment being
>  segment at the egress/ingress LSRs, each segment being
   associated with one MPLS interface.  These are also
   referred to as tunnel segments.

2) LER or LSR?
Throughout, you use (e.g.) "ingress LSR". Architecture would 
have us say "ingress LER".

3) Section 2 (and several other places)

   An explicitly routed LSP (ERLSP) is referred to as an MPLS
   tunnel.  It consists of one in-segment and/or one out-
   segment at the ingress/egress LSRs, each segment being
   associated with one MPLS interface.  These are also
   referred to as tunnel segments.  Additionally, at an
   intermediate LSR, we model a connection as consisting of
   one or more in-segments and/or one or more out-segments.
   The binding or interconnection between in-segments and out-
   segments in performed using a cross-connect. These objects
   are defined in the MPLS Label Switch Router MIB [LSRMIB].

Your implication here (and explicit statement elsewhere) is 
that an ingress may have just one out-segment and that an 
egress may have just one in-segment. This is an unnecessary
restriction:
- there is nothing to prevent multiple segements in this 
  MIB module
- there is nothing to prevent multiple segements in the
  LSR MIB module
- there is nothing to prevent multiple segements in the
  signaling protocols
- it is quite feasible (especially at the egress) that
  multiple segments will exist.

Simply remove the text.

4) Section 5

<  These actions may need to be accompanied with corresponding
>  These actions may need to be accompanied by corresponding
   actions using [LSRMIB] to establish and configure tunnel
   segments, if this is done manually.

5) Section 5

   Also, the in-segment
   and out-segment performance tables, mplsInSegmentPerfTable
   and mplsOutSegmentPerfTable [LSRMIB], should be used to
   determine performance of the tunnels and tunnel segments.

Don't forget the mplsTunnelPerfTable.

6) Section 5.1

Don't forget the mplsTunnelPerfTable.

7) Section 6.1

This table talks about segments. There are no segments in the 
TE-MIB module.

Are you worried about support of p2mp and mp2p tunnels? If so:
i)   The non-support of such tunnels should be made clear
     earlier in the document
ii)  You will need to clarify why you talk about support of
     multiple in/out segments (yes, I understand there are
     reasons appart from p2mp/mp2p, but you will need to 
     state them).
iii) You will not need to worry about the distinction 
     between Source LSR Id and Extended Tunnel Id.

8) Section 6.3, 6.4 and 6.5

Please state the meaning of the HopTable, ARHopTable and 
CHopTable at transit and egress LSRs.

9) Section 6.4 and 6.5

Please qualify further by pointing out that ARHopTable and
CHopTable are only relevant if signaling is used.

10) Section 6.7

Please add something like...

The mplsTunnelCRLDPResTable does not need to be supported 
by implementations that do not support the CR-LDP 
signaling protocol.

11) Section 9

Since you're using createAndGo, I think you need to put the
dependent tables first. Otherwise your C&G on the tunnelTable
will fail.

12) Section 9 HopTable

   The following denotes the beginning of the network, or the
   first hop. We have used the fictitious LSR identified by
   "192.168.100.1" as our example head-end router.

and

   The following denotes the end of the network, or the last
   hop in our example. We have used the fictitious LSR
   identified by "192.168.101.1" as our end router.

Who can truly say where a network begins and ends?

13) Section 9 First entry in HopTable

     mplsTunnelHopType               = loose (2),

I think you'll want to make this strict.

14) Section 9 mplsTunnelHopPathOptionName

The way I read the description of mplsTunnelHopPathOptionName
the name applies to the entire path option identified
by mplsTunnelHopPathOptionIndex.

That means that in your example you should either change
the mplsTunnelHopPathOptionIndex for the two hops, or not
change the mplsTunnelHopPathOptionName.

16) MIB Revision history

   DESCRIPTION
<       "Initial draft version issues as part of RFC XXXX."
>       "Initial draft version issued as part of RFC XXXX."

17) mplsTunnelIndexNext

Please add text to explain that this object is only used
at ingress LSRs. At transit and egress LSRs for manually
provisioned tunnels, the value of mplsTunnelIndex should
be copied from tunnelTable at the ingress. For signaled
tunnels, the value of mplsTunnelIndex should be filled in
by the signaling protocol.

18) mplsTunnelEntry Desription

        A tunnel entry needs to be uniquely identified across
          a MPLS network. Indices mplsTunnelIndex and
<         mplsTunnelInstance uniquely identify a tunnel on an
>         mplsTunnelInstance uniquely identify a tunnel on the
          LSR originating the tunnel.  To uniquely identify a
<         tunnel across a MPLS network requires index
>         tunnel across an MPLS network requires index
<         mplsTunnelIngressLSRId.  Last index
>         mplsTunnelIngressLSRId.  The last index
          mplsTunnelEgressLSRId is useful in identifying all
          instances of a tunnel that terminate on the same
          egress LSR."

19) mplsTunnelEntry indexing

I believe the order of indexes is wrong. Since tunnelIndex is in
the context of the ingress it should follow the ingressLSRid. 
This will allow you to easily find all locally originated tunnels.

Since the tunnel index is part of the Session object and is
technically subsidiary to the destination address it makes sense
to make the index ordering

   INDEX {
      mplsTunnelIngressLSRId,
      mplsTunnelEgressLSRId,
      mplsTunnelIndex,
      mplsTunnelInstance
   }

I believe this makes the table more easily searchable, but I would
also understand

   INDEX {
      mplsTunnelIngressLSRId,
      mplsTunnelIndex,
       mplsTunnelInstance,
      mplsTunnelEgressLSRId
   }

20) mplsTunnelIndex

If you refer to FRR here you should add a reference
- to the object definition
- to the informational references section

21) mplsTunnelIngressLSRId

Twice you say "mimic". What had you in mind? Heavy sarcasm or
a cartoon character? :-)

If you mean "be equal to" please say so, but see the next point.

22) mplsTunnelIngressLSRId and mplsTunnelEgressLSRId

I am very uneasy about the syntax of these objects and the
description of mplsTunnelIngressLSRId.

i)   By allowing them to be of type MplsExtendedTunnelId you
     are allowing a user to configure a non-IP address. What
     would this mean?
ii)  By saying that the ingress and extended tunnel id fields
     SHOULD be the same you are opening up confusion!
     Can we keep the two separate concepts in separate objects
     please?  That is, have an object called 
     mplsTunnelIngressLSRId and one called mplsTunnelExtTunnelId.
     I would understand if the second were read-only although I 
     think you should give the option of write access with some
     default behavior.
iii) Could you please describe how these objects map to 
     signaling. I suspect that doing so will help resolve the
     two previous points.

23) mplsTunnelIsIf

I think a note explaining that at transit LSRs this MUST be
set to false would be good. Maybe section 8 should talk about
mapping tunnels to interfaces at egress LSRs.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 27 Jun 2003 13:04:09 -0400

As promised, here is the continuation of my review of this draft.

This concludes my comments. I'm afraid I don't have the stamina to
work on the conformance statement.

Adrian

=========

24) mplsTunnelResourcePointer Description

This refers to "segment" twice. But we are not dealing 
in segments in this MIB table. We are dealing in 
tunnel instances (or if you must, LSPs).

25) mplsTunnelPrimaryInstance

It is very unclear what you mean in this case by 
"primary". I think the description needs to be enhanced.

For example, do you mean the tunnel instance that is 
actually established and active at the moment? No, it
can't be that because in mplsTunnelInstancePriority
allows two instances to be active at once.

Does it mean "preferred"? Wouldn't that be covered
by the instance with the highest priority?

Perhaps it means the instance that carries the full 
configuration? No this is the definition of the row
with tunnel instance zero.

26) mplsTunnelTable

Given that I have a tunnel with many instances defined,
how do I find which instance(s) are currently active?
Do I have to read each of them and collect the ones
with operStatus up?

27) mplsTunnelInstancePriority

        "This value indicates which priority, in descending
          order, with 0 indicating the lowest priority,
          within a group of tunnel instances. A group of
<         tunnel instances is defined as a set of tunnels
>         tunnel instances is defined as a set of LSPs
          with the same mplsTunnelIndex in this table, but
<         with a different mplsTunnelInstance. Tunnel group
>         with a different mplsTunnelInstance. Tunnel instance
          priorities are used to denote the priority at which

28) mplsTunnelRole (out of order, sorry)

   SYNTAX        INTEGER { head(1), transit(2), tail(3) }

I believe you need BITS not INTEGER since a tunnel may
be set up between interfaces on a single LSR making it
both ingress and egress. You could alternatively add:

   head_tail(4)

but I think that is less useful.

29) mplsTunnelExcludeAllAfinity

As Ed says, this should read "Any". Also in the description.

30) mplsTunnelPrimaryUpTime

This description is inadequate.
What is meant be "active"?
See point 25) for questions about what a primary instance is.
Is this value present in the row for every instance that is
not a primary instance? If so, why?

31) mplsTunnelPathChanges

<       "Specifies the number of times the paths has changed
>       "Specifies the number of times the path has changed
          for this tunnel since its creation."

32) mplsTunnelPathChanges and mplsTunnelLastPathChange

Do you mean "for this tunnel instance" or are you trying 
to capture the case where a tunnel has changed path by
any means including a change of instance?

What do you mean by "path change"? Hop, CHop or ARHop?

33) mplsTunnelCreationTime

Please be more specific. What does "came into existence" mean?

34) mplsTunnelStateTransisitions

Please say which "state" you are refering to.

35) mplsTunnelOperStatus (and probably all operStatus objects)

At the MIB Meeting (TM) we took an action that "unknown" 
would always have value (1) unless there was good reason in
which case it must be stated in the MIB modules.

36) mplsTunnelRowStatus

        "This variable is used to create, modify, and/or
<         delete a row in this tabole.  When a row in this
>         delete a row in this table.  

37) mplsTunnelRowStatus

           When a row in this
          table is in active(1) state, no objects in that row
          can be modified except mplsTunnelRowStatus and
          mplsTunnelStorageType."

Can be modified by whom/what? Presumably a dynamic signaling
protocol could modifiy this table regardless of the rowStatus.

Can a user not change the adminStatus when rowStatus is
active?

38) mplsTunnelStorageType (and all similar fields).

The text here is confusing.

        "This variable indicates the storage type for this
          object.  If this variable is set to readOnly(5),
          and the corresponding entry is removed, then the
          agent must remove this row shortly thereafter
          [RFC2579].

What is the difference between an "entry" and a "row"?
Where you say "entry", do you mean "the managed object
represented by this entry in the table"?

        Setting this object to permanent(4) indicates that
          this object should be restored automatically after
          failures.

What do you mean by "this object"?
Do you mean the "managed object represented by this entry
in the table"?

39) mplsTunnelHopListIndexNext

Shouldn't the syntax be MplsPathIndexOrZero?

40) All IndexNext objects

I recall an email discussion with Bert about how these 
objects should be managed and described. The concern is
with producing unnecessary lacunae in the table.

I think the position "agreed" upon was to cut over to
using the IndexInteger and IndexIntegerNextFree TCs 
from RFC3289.

41) mplsTunnelHopTable

Please explicitly state the meaning of this table for
LSRs that are not the ingress of the tunnel instance.

This text should also be placed in the description of
mplsTunnelHopTableIndex.

41) mplsTunnelHopTable

        "The mplsTunnelHopTable is used to indicate the hops,
<         strict or loose, for an MPLS tunnel defined in
<         mplsTunnelTable,
>         strict or loose, for an instance of an MPLS tunnel
>         defined in mplsTunnelTable,

42) mplsTunnelHopTable

                           when it is established via
          signalling, for the outgoing direction of the
          tunnel.  

What does this mean? 
i)  Why is it limited to signaling? This is a convenient
    place to record the path of a manula tunnel instance 
    if it is known.
ii) Are you trying to say that the only hops present are
    the downstream hops? Thus in RSVP-TE terms, at 
    transit LSRs, this matches the received ERO. If so,
    please say so.

43) mplsTunnelHopTable

                                                      The
          first row in the table is the first hop after the
          origination point of the tunnel.  

In which case your example in section 9 is broken.

44) mplsTunnelHopAddressType

          mplsTunnelHopAddrUnnum should be referred to. If
          the object is set to lspid(5), then all but the
          mplsTunnelHopLspId should be referred to. Note that
          lspid(5) is a valid option only for tunnels
          signaled via CRLDP"

What do you mean by "all but the mplsTunnelHopLspId should
be referred to"?

45) mplsTunnelHopAddress

I am confused by this object and the associated textual 
convention.

i)  Why are 32 octets required to carry a hop address?
ii) Is there not already a standard TC for carrying IP
     addresses?
iii) If you are going to use a "free-form" octet string
     (not my favorite) then why is it necessary to 
     have a separate object and TC for AS number?

46) mplsTunnelHopAddrUnnum

If this only holds the interface id, where is the 
router id?

47) mplsTunnelHopType and mplsTunnelHopInclude

I believe you should combine these since strict/loose
has no meaning for exclusion.

This gives...

mplsTunnelHopType OBJECT-TYPE
   SYNTAX        INTEGER {
                      strict(1),
                      loose(2),
                      exclude(3)
                     }
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "Denotes whether this tunnel hop is routed in a
          strict or loose fashion, or is to be excluded
          from the computed and actual paths."
   ::= { mplsTunnelHopEntry 10 }

48) mplsTunnelHopPathOptionName

Must this be present for every hop with the same
mplsTunnelHopListIndex and mplsTunnelHopPathOptionIndex?

If so, must it be identical?

49) mplsTunnelHopEntryPathComp

So many questions!

i)   This is not a per hop piece of information. This
     and point 48) suggest that you need a PathOption
     table.
ii)  How is this useful? It seems you are mixing two
     issues. a) the need to control whether CSPF or
     simple next-hop routing should be invoked at the
     ingress, b) whether the user is allowed to 
     specify other than the ingress and egress
     addresses.
iii) Note that the user cannot specify the ingress
     since the source is not in the hop table!

50) mplsTunnelHopRowStatus

"tabole"

51) mplsTunnelResourceTable

An old chestnut, this one...

Does this table hold the requested values or the actual 
values? In other words, what effect does Admisssion 
Control and Resv have on the objects in this table?

What does the table betoken at non-ingress nodes? The
values received on the setup request?

When you say the values are copied into LSR MIB module
objects, are you implying that the two objects always
contain the same values?

52) mplsTunnelResourceExBurstSize, 
    mplsTunnelResourceFrequency and 
    mplsTunnelResourceWeight

These seem to be duplicated by...
    mplsTunnelCRLDPResExBurstSize, 
    mplsTunnelCRLDPResFrequency and 
    mplsTunnelCRLDPResWeight

Must I use both?

53) mplsTunnelResourceRowStatus

"tabole"

54) mplsTunnelARHopTable

Need a description of the menaing of this table at 
non-ingress nodes.

The question is whether this reflects the RRO from
the Resv, or the splice of the RRO from the Path 
and the Resv.

55) mplsTunnelARHopTable

        "The mplsTunnelARHopTable is used to indicate the
          hops, strict or loose, for an MPLS tunnel defined

How can there be a loose hop in the ARHopTable? Fortunately
you don't have an object for this.

56) mplsTunnelARHopTable

         Please note that since the information necessary to
<         build entries within this table are not provided by
>         build entries within this table is not provided by

56) mplsTunnelARHopTable

I believe it is important to add a note to point out that the
contents of this table may change while you are walking it.
This may lead to the NMS perceiving a path which appears to
include loops.

You should mention that the mplsTunnelLastPathChange object
can be used to verify that the AR read is valid.

57) mplsTunnelARHopEntry

        "An entry in this table represents a tunnel hop.  An
          entry is created by a network administrator for
          signaled ERLSP set up by an MPLS signalling
          protocol."

Huh? Surely it is created by the signaling protocol.

58) mplsTunnelARHopAddrUnnum (and all unnum addresses)

I just noticed the TC for this is an OctetString.
Why? What is wrong with putting 32 bit values in 32 bit
objects?

59) mplsTunnelARHopIpPrefixLen

How would this ever be other than a full prefix?
In other words, this object is redundant.

60) mplsTunnelARHopAsNumber

How do you expect this to be present in the AR?
There is no way to signal it.

61) mplsTunnelARHopTable

What about labels and local protection flags (both in
the RRO in RFC3209)? Are we defering these only to the
GMPLS MIB?

62) mplsTunnelCHopTable

        "The mplsTunnelCHopTable is used to indicate the
          hops, strict or loose, for an MPLS tunnel defined
          in mplsTunnelTable, as computed by a constraint-
          based routing protocol, based on the
          mplsTunnelHopTable for the outgoing direction of
          the tunnel.  Each row in this table is indexed by

What do you mean by the "outgoing direction of the tunnel"?
Are you trying to say that this table only holds information
for LSRs downstream of this LSR (which would make it 
behave as the mplsTunnelHopTable, so seems reasonable) please
use standard terms.

This ties to the question: what is the menaing of this table
at non-ingress LSRs? It clearly could have value everywhere 
except the egress.

63) mplsTunnelCHopTable

          table is optional. Furthermore, since the
          information in this table is actually provided by
          routing protocol after the path has been computed,
          the entries in this table are provided only for
          observation, and hence, all variables in this table
          are accessible exclusively as read-only."

I think this could be reworded.

          Furthermore, since the information in this table
          describes the path computed by the CSPF engine
          the entries in this table are read-only."

64) mplsTunnelCHopEntry

        "An entry in this table represents a tunnel hop.  An
          entry in this table is created by a constraint-
          based routing protocol based on the hops specified
          in the corresponding mplsTunnelHopTable."

Hmmm. A new and wonderful use for a routing protocol!
Reword...

        "An entry in this table represents a tunnel hop.  An
          entry in this table is created by a path computation
          engine using CSPF techniques applied to the 
          information collected routing protocols and the hops
          specified in the corresponding mplsTunnelHopTable."

65) mplsTunnelPerfTable

<       "This table provides per-tunnel MPLS performance
<         information."
>       "This table provides per-tunnel instance MPLS 
>         performance information."

66) mplsTunnelPerfTable

Should we not also measure the signaling protocol?

67) mplsTunnelPerfTable

What about packets dropped because of local resource
constraints? Such packets are received successfully and are
not packets with errors, but may be discarded through queuing
precidence or whatever.

68) mplsTunnelCRLDPResMeanBurstSize

Isn't this a duplicate of mplsTunnelResourceMeanBurstSize
which is not specifc to CR-LDP?

69) mplsTunnelCRLDPResEntry

Please state rules to prevent one of these entries being
orphaned.

70) mplsTunnelCRLDPResRowStatus and
    mplsTunnelCRLDPResStorageType

Why not inherrit from mplsTunnelResourceEntry?

71) mplsTunnelDown

mplsTunnelRowStatus is needed too since it may explain why
operStatus has gone down even though adminStatus is up.

72) mplsTunnelRerouted

        "This notification is generated when a tunnel is
          rerouted. If the actual path is used, then this
          tunnel's entry MAY contain the new path for this
          tunnel some time after this trap is issued by the
          agent."

What is meant by "If the actual path is used"? Are you 
saying...

        "This notification is generated when a tunnel is
          rerouted. If the mplsTunnelARHopTable is used, 
          then this tunnel instance's entry in the 
          mplsTunnelARHopTable will contain the new path 
          for this tunnel some time after this trap is
          issued by the agent."

73) mplsTunnelReoptimized

ditto

74) Section 12   First bullet

mplsTunnelARHopTable and mplsTunnelCHopTable are read-only
and so should not appear at this point.

75) Section 16

It is no longer 2001 (although it may still feel like it :-)