Subject: Comments on draft-ietf-mpls-te-mib-03.txt

From: Adrian Farrel <[email-masked]>
Date: Mon, 20 Mar 2000 11:01:49 -0000

Hi Tom, Arun, Cheenu.

I've now had a chance to read the latest draft of the TE MIB 
(the benefits of long-haul flights!).

Good work, the MIB is definitely stabilizing.

As usual I have a bunch of comments which I have classified.  I
hope these are of use to you.

Major Omissions

1. Control of Notifications
   I regard it as important to allow a facility for the 
   Management Tool to disable notifications to save resources.
   In an email to Tom on 5th Jan I suggested some ASN.1 for two
   top level objects to achieve this.
   Do you have any objections to adding this function?
   Would you like me to resend you the ASN.1?

2. Support for configuring DiffServ LSPs
   draft-ietf-mpls-diff-ext is well progressed. I think it would
   be sensible to offer support for configuring E-LSPs and L-LSPs
   at the ingress. Do you agree?
   In the above-mentioned email to Tom, I suggested some ASN.1 to
   achieve this.  Would you like me to resend it?
   I suspect that the ASN.1 should be run past the authors of the
   diff-ext draft to check that it is in line with their 
   requirements.

3. LSPId explicit hop type
   Is there any reason to prevent configuration of an explicit hop
   of type LSPId?  I suggested some ASN.1 for this in an email to 
   Tom on 7th Jan.

4. Non-use of ERO
   This is a bit philosophical :-Z
   If I know my egress but I have no requirement to specify an ER, I
   can set up just one hop showing a loose hop to the egress.
   How can the protocol code tell the difference between a request to
   use an ER object/TLV with a single hop, and a request to use no 
   ER object/TLV?

   Things that influence this are
   - is the route pinned?
   - do all of the LSRs on the route support ER?
   Clearly the protocol code can make a local policy decision on 
   whether to include the ER object/TLV based on this information. 
   Without appropriate configuration, it may be necessary (e.g. in 
   RSVP) to experiment by sending an ER and finding out if the LSRs
   on the path reject it.

   Would it be worth adding mplsTunnelEgress to the main TunnelTable
   thereby allowing the ER to be omitted?

Questions/Clarifications

5. Make before break
   I think that the TunnelInstance object gives the facility for 
   controlling make before break, but I believe it would enhance the
   draft to add some explanation of how this field can be used.

6. MPLS Tunnel Resource Table
   This table is a welcome addition.
   I believe you need to be very careful because of the differences 
   between forward and reverse resource reservation.  For example,
   for an RSVP tunnel, what is configured here must be the TSpec.  
   Clearly, sharing TSpecs is useful from a configuration point of 
   view, but says nothing about sharing of resources which is 
   determined elsewhere in the network.  Is it your intention that
   this table is updated on the reverse path?
   
7. MplsTunnelIndex
   Although current MPLS tunnels signaling protocols only support 
   16 bits to identify a tunnel from a specific ingress, it may be
   that some future protocol will allow a greater number of tunnels.
   Would it be wise to prepare for this by allowing MplsTunnelIndex 
   to have a greater range?

8. Cookies
   These are defined as read-only. Do we need write access to
   configure them for bi-directional tunnels?

9. mplsTunnelHopTable
   This is currently indexed by mplsTunnelIndex.  Does this mean that
   different instances of a tunnel as defined by mplsTunnelInstance
   cannot have different routes?  
   If you add mplsTunnelInstance as an index to the HopTable, it means
   that each instance must have its own ER defined and cannot share the
   definition for all instances of the same LSP.

10. mplsTunnelHopTable
   The description says that you can specify the outgoing interface at 
   the tunnel ingress through the first hop of the ER.  Is this done
   using the IP address for the interface?

Editorial

11. Example
   The example in section 7 needs updating in line with the changes
   to the tables.
   - IsMergeable, IsPersistent and LocalProtectInUse are no longer
     objects in the table.
   - TunnelIfIndex, LocalCookie and RemoteCookie are read-only so 
     shouldn't be modified here.
   - The example values for some of the objects are, perhaps, a 
     little unusual for some of the objects (e.g. TunnelDirection,
     RemoteCookie)
   - Would you expect to set the In and Out resource values for an
     'in' tunnel.

12. References
   The version numbers of the referenced drafts in DESCRIPTION fields
   in the MIB tables need updating.  I believe that any drafts 
   referenced in this way need to be flagged as "work in progress".

13. Terminology
   In a couple of places you have used ERLSP.  It's a bit pedantic,
   but I think we should refer to CRLSP (or perhaps just LSP) since 
   explicit routes don't have to be used.

14. Textual Convention for IP Addresses
   I believe that there is a move to define a single textual convention 
   to cover IPv4 and IPv6 addresses.  The aim is to avoid the need for 
   each new MIB to define its own textual convention.  It might be worth 
   looking into this.

15. mplsTunnelXCIndex
   It would be good to expand on the Description.  Explain that this
   object is only writeable in conjunction with pre-existing entries
   in the LSR MIB.  Say that in normal signaled operation this object
   will be set by the LSR.  Explain the meaning of zero.

16. mplsTunnelSignallingProto
   Assuming future protocols will come along, would it be tidier to 
   set the value of 'other' higher to allow space for future extension?

17. BITS
   I'm uneasy about the use of BITS for mplsTunnelSessionAttributes.
   Asides from whether this is standard in MIBs, I don't see the need.
   Why not keep the bit fields as separate objects?

18. Defaults for mplsTunnelSessionAttributes, 
   mplsTunnelInstancePriority and mplsTunnelAdminStatus

19. MplsTunnelResourceEntry.
   Most of the objects describe mappings to the objects in the 
   mplsTSpecTable of the LSR MIB in terms of "copying".  I think you
   should relax your text a bit and just say that the values correspond
   to the values of the objects in the mplsTSpecTable.

20. MplsTunnelARHopEntry
   I can see that mplsTunnelARHopAsNumber would be useful or 
   interesting to ISPs (perhaps they would edit the RRO on exit from
   their AS, but this is currently not supported by the signaling
   protocols.

21. Notifications
   Add mplsTunnelInstance.

Typographic

Section 7, paragraph 1, line two.
Insert "a" to read "create a loosely routed"

Formatting needs a little tidying up in places
- section 7, mplsTunnelIsPersistent
- section 8, Imports
- MplsTunnelEntry
- mplsTunnelOperStatus
- mplsTunnelResourceEntry
- mplsTunnelGroup

Integer options
It is usual to list these with each entry on a new line (e.g. 
mplsTunnelDirection).

mplsSessionAttributes.
- The Description refers to fastReroute, the bit is called
  ingressMayReroute
- localProtectionAvailable "det4ected"
- isPinned "Indicates" read "indicates"

mplsTunnelOwner.  Value 2 is called 'ldp'.  Risking the dangerous
political field, can I suggest that this should be 'crldp'.

mplsTunnelInstancePriority first line for "which" read "the"

mplsTunnelInstancePriority line 8 for "particular a" read "a
particular"

mplsTunnelResourceIndexNext/mplsTunnelResourceIndex
Decide on common syntax.  Zero should not be a valid value for
mplsTunnelResourceIndex

mplsTunnelResourceInMaxRate etc.
MplsBitRate is defined in the LSR MIB in 1,000 bits per second.
The descriptions for these fields need updating.  Additionally,
the UNITS tag is ood.

mplsTunnelHopStrictOrLoose  Delete "is" to read "this tunnel hop"

mplsTunnelARHopEntry "represents an currently"

--
Adrian Farrel  mailto:[email-masked]
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 20 Mar 2000 08:20:18 -0500

Hi Adrian,

         As Cheenu, Arun and I will reply to your questions/
comments shortly. Arun is out of town for the next day
or so, so we may not get back to you until later in the
week.

         --Tom