The MPLS WG Archive

["Adrian Farrel" <afarrel@movaz.com>]

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.